<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks for directing me to this, I missed it.<div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Most projects will not conform to these conventions.<br class=""></blockquote><div class=""><br class=""></div>Giggle. Kind of an understatement, no?</div><div class=""><br class=""></div><div class="">Like, okay. Here is a project I'd like to package. (Read: I do package it, with features not in mainline swiftPM.) <a href="https://github.com/jedisct1/libsodium" class="">https://github.com/jedisct1/libsodium</a></div><div class=""><br class=""></div><div class="">Let's take a look at how this package realistically builds:</div><div class=""><br class=""></div><div class="">* It has tests ("make check")</div><div class="">* It has various --enable-foo flags</div><div class="">* It swaps in special implementations depending on if you have <a href="https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L162" class="">AMD64</a> or <a href="https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L145" class="">AVX instructions</a> or <a href="https://github.com/jedisct1/libsodium/blob/master/src/libsodium/Makefile.am#L229" class="">SSE2</a> etc.</div><div class="">* The optimization level is tuned on a <a href="https://github.com/jedisct1/libsodium/blob/master/dist-build/android-armv7-a.sh#L3" class="">per-architecture basis</a></div><div class="">* They build (also) on Windows. They're not changing how they're packaged for "SwiftPM, the Mac/Linux build system".</div><div class="">* Oh and this is cryptography code. Do you *really* want to touch it?</div><div class=""><br class=""></div><div class=""><b class="">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</b>. 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 2, 2016, at 11:00 AM, Daniel Dunbar via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Happy 2016!<br class=""><br class="">I am working on an initial proposal for adding support for C language targets to the Swift package manager, and am interested in feedback:<br class=""> <a href="https://github.com/ddunbar/swift-evolution/blob/master/proposals/NNNN-swiftpm-c-language-targets.md" class="">https://github.com/ddunbar/swift-evolution/blob/master/proposals/NNNN-swiftpm-c-language-targets.md</a><br class=""><br class="">Some TL;DR:<br class=""> - 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).<br class=""> - 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.<br class=""> - 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.<br class=""><br class="">Unless there are serious objections, I am hoping to hope to land this proposal soon and start work on the feature shortly after.<br class=""><br class="">Cheers,<br class=""> - Daniel<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-build-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>