[swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support
drew at sealedabstract.com
Sat Jan 2 15:57:15 CST 2016
Thanks for directing me to this, I missed it.
> Most projects will not conform to these conventions.
Giggle. Kind of an understatement, no?
Like, okay. Here is a project I'd like to package. (Read: I do package it, with features not in mainline swiftPM.) https://github.com/jedisct1/libsodium <https://github.com/jedisct1/libsodium>
Let's take a look at how this package realistically builds:
* It has tests ("make check")
* It has various --enable-foo flags
* It swaps in special implementations depending on if you have AMD64 <https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L162> or AVX instructions <https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L145> or SSE2 <https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L229> etc.
* The optimization level is tuned on a per-architecture basis <https://github.com/jedisct1/libsodium/blob/master/dist-build/android-armv7-a.sh#L3>
* They build (also) on Windows. They're not changing how they're packaged for "SwiftPM, the Mac/Linux build system".
* Oh and this is cryptography code. Do you *really* want to touch it?
I think an important feature of any C target proposal is that there will actually exist C targets which can be built under the proposal. Until there are C people coming out of the woodwork saying "sure, I will repackage my software this way" I think the entire value is debatable.
Getting signoff from libdispatch/CoreFoundation is necessary but not sufficient to clear that hurdle. I would think getting the other C deps in our own project family to repackage would be "table stakes" for any new C build system. The real test are projects that are third-party and less friendly.
And I do not see realistically how we are ever going to support a project like libsodium, except calling out to automake. An automake solution coincidentally supports both libdispatch and CoreFoundation right now. IMO something like that is a much, much better direction in the short-term, and once we have done the first step of "packaging" those software via automake we will have "real" C projects in our package manager and we can design our C support around the concerns of real projects instead of imaginary ones.
> On Jan 2, 2016, at 11:00 AM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> Happy 2016!
> I am working on an initial proposal for adding support for C language targets to the Swift package manager, and am interested in feedback:
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a lot of add on work which I expect should be tackled in follow on PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., exactly what C++ standard we will compile with). My intention is to pick a sensible default at implementation time and refine incrementally.
> Unless there are serious objections, I am hoping to hope to land this proposal soon and start work on the feature shortly after.
> - Daniel
> swift-build-dev mailing list
> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution