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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-build-dev
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
