[swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Drew Crawford]

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:
>  https://github.com/ddunbar/swift-evolution/blob/master/proposals/NNNN-swiftpm-c-language-targets.md
> 
> 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.
> 
> Cheers,
> - Daniel
> 
> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160102/58766af5/attachment.html>