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.
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
