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-...@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-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to