[swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[Daniel Dunbar]

> On May 23, 2016, at 3:34 PM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev at 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 at 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 at swift.org> wrote:
>>> 
>>> Hi David,
>>> 
>>>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev <swift-corelibs-dev at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> _______________________________________________
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev