[swift-corelibs-dev] relationship of CF

Sat Jan 2 18:33:10 CST 2016

I think perhaps it might be worth something to investigate on what it would take to get these extra platforms integrated into CI as nodes to the Swift primary builders. As a note since we do target ARM as a primary platform for Darwin and we do target Linux as a primary platform, ARM linux is not a far stretch so the Pi is much more “supported” than other targets like the initial question of Windows code paths at the current moment.

Perhaps one of the compiler team can chime in since the packaging and automatic builds are their domain and not per-se mine.

> On Jan 2, 2016, at 1:57 PM, Dave Fenton via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Given the educational angle that seems to be part of the mission of Swift, I was hoping that the Raspberry Pi port would be something the Swift project would directly integrate  and distribute 
> 
> -david
> 
> On Jan 2, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
> 
>> 
>> Responses inline:
>> 
>>> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>> 
>>> I had a question about something I saw in the docs:
>>> 
>>>> A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere.
>>> 
>>> (emphasis added)
>>> 
>>> Is the intent of this paragraph to suggest that most PRs to swift-corelibs-foundation should be a C-language implementation to CF with a light Swift wrapper?  That goes against my intuition, but it "seems to be" a plain reading of the paragraph.
>> 
>> I think the underlying intent is that we should use the right tools for the job; where it makes sense, even the standard library uses C++. Similarly some of the interfaces for ICU for example make much more sense to encapsulate with CF (and re-use some of the existing cross platform abstractions). Some classes will be a thin veneer on top of CF, where-as others will be a completely swift implementation. Take the two cases of NSCalendar and NSThread. CF provides some very hard to write (and hard to get right) implementations of calendrical math, even though I wrote a good portion of the NSCalendar swift implementation; I am definitely glad that there was an implementation I could fall back upon to deal with that logic. The counterpoint of NSThread; we could have wrapped up a CFThreadRef type object and bridged it across but It made sense to keep NSThread in the realm of Swift not only for a potential example of dealing with posix APIs for the community but also it just worked out more cleanly in my opinion.
>> 
>> I have not crunched the numbers but I have a gut feeling that a large majority of the pull requests have been mostly Swift implementations and only a few of them have been thin veneers on-top-of CF and even fewer have been changes to CF itself.
>> 
>>> 
>>> its justification about "all platforms" is also strange–I know CF "kind of" builds for Windows, but is anyone actually testing it there?  To make sure we aren't breaking it?  Or does "all platforms" mean something else here?
>> 
>> I know there have been efforts to port swift to FreeBSD and to new architectures like ARM-elf for things like Raspberry Pi, I would not be surprised that there are efforts to port to Android or Windows out there. Granted we do not have any CI provided by Apple to ensure not breaking these efforts but I think that the community will be interested in keeping these things running since a cross platform framework and language are really appealing (even Apple makes a few products for Android and Windows…)
>> 
>> As of current the Windows target is not held directly from the point at which this CF was cut from; so I would probably say “trust but verify” and I would not be surprised that there may be a few breaking points there that need to be re-looked at for that platform. I am certain that if someone took up a new target like Windows that would be met with great enthusiasm from all of the swift community. I was ecstatic when I saw that there was a FreeBSD port.
>> 
>> I think the one major thing to take under consideration is that alternate platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI that the swift project maintains. I think however if there is strong desire out there it would be interesting to have externally maintained build servers provided by the community to verify these targets. I am not in charge of that type of decision but I would definitely think that it would be an amiable goal and I would think that it would be worthwhile to discuss further.
>> 
>>> 
>>> I feel like this paragraph is an opportunity to explain to a patch author how to structure their patch between use/maintenance/contributions to the CF layer vs the Swift layer.  I feel like it could do a much better job, but I don't understand what the design guidance actually is, so I can't fix it.
>>> 
>> 
>> Things that enter into CF territory will be things that we will consider with a very close eye on them because they will likely move up-stream into the CoreFoundation that ships with our current platforms so that the lifecycle completes back out to the exported version in the open-source side of it.  The Foundation part of the story is a bit more mutable since we have the Objective-C version that will still be maintained. That being said there is a very strong desire to keep these in parity; we may use some of the interfaces in the swift version to try out what people think of these APIs (most of these are marked with experimental, and if they are not we should either correct them to be the same or mark them as such). Furthermore the swift version will sometimes drive internal efforts to improve Foundation as a whole not just it’s swift exposition. We have already had a few proposals that are making their ways to the component owners and teams that will improve the state of affairs for not just swift but objc too as externally authored proposals. 
>> 
>> I agree that some of this intent should be a bit more clearly laid out; I will discuss about this when I get back into the office Monday and see what we can come up with to more clearly illustrate what is expected, what types of fallout patches have, and how the process will work for each potential layer and interaction.
>> 
>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> _______________________________________________
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>  _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160102/7fe480c3/attachment.html>