> On May 23, 2016, at 3:34 PM, Philippe Hausler via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > There are a few considerations for the package manager: we may have circular > build requirements, swift-corelibs-foundation does some squirrelly things > with linking and compilation like linker scripts and tacked on assembly data > segments. I am not certain those edge use cases are supported yet.
They are not, and I would view them as a stretch for 3.0 at this point. The combination of this and the circular build problem makes me think that we should probably expect to maintain a Foundation-specific build solution for the time being. - Daniel > > The Python config file is way too complex as it is and was only really > designed as a stopgap measure. If we can simplify I think it would definitely > improve the state of things: it is worth investigating. > > Sent from my iPhone > >> On May 23, 2016, at 3:03 PM, David Hart via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >> Would you agree that the first step should be to have the project as a >> SwiftPM package so that we have a more consistent way to run tests on all >> platforms? Do you know if SwiftPM is far enough to support >> swift-corelibs-foundation? I might have a go at it once I finish >> implementing NSProgress (about half way through I think). >> >>> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev >>> <swift-corelibs-dev@swift.org> wrote: >>> >>> Hi David, >>> >>>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev >>>> <swift-corelibs-dev@swift.org> wrote: >>>> >>>> Hello, >>>> >>>> The discussion we had previously on this mailing list made it quite clear >>>> that: >>>> >>>> - Objective-C Foundation is the framework that is supposed to be used on >>>> all Darwin platforms, >>>> - swift-corelibs-foundation will be the Foundation framework for all other >>>> platforms, >>>> - Both frameworks will evolve slowly together. >>> >>> Yup. >>> >>>> >>>> Therefore, it makes sense that for code written against Foundation to be >>>> portable, the swift-corelibs-foundation APIs and behavior needs to be >>>> identical to Darwin Foundation. Hence the following questions? >>>> >>>> - Shouldn't we be writing tests in a way so that they can be run against >>>> Darwin Foundation and have the CI Server run them? For example: while >>>> working on NSProgress, I write a bunch of tests against Darwin Foundation, >>>> make sure they pass, then copy-paste them in the CoreLibs project, and fix >>>> the implementation until they pass. This makes sure that both APIs are >>>> consistent with each other. I was thinking that we ought to automate this >>>> and have the CI server test them. >>> >>> That would be a great step. This is part of the reason we tried to set up >>> the dependencies of Foundation on XCTest the way we did, and provide the >>> Xcode project file; so we could share tests. I would welcome any help we >>> can get on improving our automation story here. >>> >>>> >>>> - How are we planning to reconcile the API differences between both >>>> frameworks? For examples, one of my tests will run against CoreLibs but >>>> not against Darwin because NSThread.init takes a closure as argument in >>>> CoreLibs but a target+selector in Darwin. This is just one example, but I >>>> guess they are other inconsistencies elsewhere. This seems to be >>>> particularly the case with APIs that rely on the Objective-C runtime. >>> >>> These should be marked as “experimental” in the documentation comments. If >>> not, we should do that. >>> >>> There are some areas where we just don’t know what to do yet, because of >>> the lack of the ObjC runtime and implicit bridging on Linux. In some of >>> those places we’ve tried to provide a replacement API and mark it as >>> experimental until we can figure out the larger story. >>> >>>> In general, I'm starting to worry about the state of Foundation from a >>>> portability point of view. Once Swift 3 is released, I want to start >>>> writing portable swift code that relies on Foundation. And it seems like >>>> this will require a huge amount of #if os() everywhere to cope with the >>>> differences. >>>> >>>> David >>> >>> Our long term goal is to enable developers to do this. I acknowledge that >>> we have a ways to go to get there. I’ve seen an uptick in contributions >>> recently, which gives me hope that we can get closer before the release of >>> Swift 3. >>> >>> - Tony >>> >>> _______________________________________________ >>> swift-corelibs-dev mailing list >>> swift-corelibs-dev@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
