Working my way through the swift-corelibs-foundation for Windows, I think I have gotten to the point where I believe that the last items preventing Windows support for Foundation can now be enumerated:
Porting the remaining interfaces in Process, Thread, FileManager, and Host
Fixing the VWT handling for ForeignClassMetadata strategy
Fixing protocol witness table emission to be exported from the standard library
Identifying the desired behaviours for curl/libxml2 linkage
The first three are more technical, the implementation for the interfaces just need someone dedicated enough to work through the surface and with some time. The second would be something that is more involved, the third is just a bug.
The last item however is a bit more challenging. It is entirely a policy type of problem. Do we want to have the linkage be static or dynamic? Or do we want to have the ability to control that? There are pros and cons to both approach, and its unclear what the larger population is using and prefers. I don't have a strong opinion on either direction for this, but would prefer to have a single way that is supported so we do not need to have an option to control this explicitly (although, if there is a reason to have that, it is okay, as long as it is a conscious decision). So, I figure that this might allow people to chime in so an informed decision can be made.
For those interested in the rest of the Windows port, especially those interested in helping getting Foundation running on Windows, do checkout the WIP PR. I would certainly love some help!
How possible is it to include CoreFoundation in the nightly builds, or even just to upload the built .lib/.dll somewhere? If that’s not too difficult, I could build and link the Foundation sources against CF (since that’s less of a hassle when cross-compiling than trying to use the proper build system) and help with some of the remaining items.
Unfortunately, there is a small detail that was never fully resolved and that is that the build of Foundation actually uses CoreFoundation as a framework on all targets. You cannot just include the .lib, but need the entire NeXStep style framework to build against and the install rules don't support that yet. If that is done, then that would be possible.
I think that replicating the build for Foundation even if it involves CF is not too bad even when cross compiling (and is in fact how I did most of the port). You do need some of the pending changes in libdispatch. Hopefully @tkremenek can help get those merged soon so that the changes needed for Foundation are limited to just the Foundation repository. I have been trying to split up some of the dependencies into individual changes but since @millenomi has been out, I'm stilling waiting on a review for those (e.g. UUID handling) . Hopefully @millenomi or @Tony_Parker can take a look at that soon.
I want to be incredibly clear, and I think I can safely say this:
Core Foundation, insofar as swift-corelibs-foundation is concerned, is just an implementation detail of Foundation. We do not give any guarantees to anyone using it directly, especially from C code, and we strongly discourage its use in Swift code that you want to make portable.
In practice, it requires some care to compile C code that can link with it. There are C and linker flags that need to be adopted by all code downstream that links to it, and I’m not keen on guaranteeing these stay stable. (In fact, one will be changing as soon as I land the split work I’ve been doing.)
What we support for cross-platform purposes:
We support writing code that imports Foundation;
We support a limited subset of code using Core Foundation (it has to a. be Swift; b. explicitly import CoreFoundation; c. not all features are source-compatible; for example, toll-free bridging with as is not supported.)
Building a Core Foundation library separately from source and then linking your own code to it will create a binary that cannot be loaded in the same process as Swift code using swift-corelibs-foundation. (Core Foundation “by itself” and Core Foundation as used in s-c-f are have different ABIs.)