<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Drew,<div class=""><br class=""></div><div class="">First off, I believe that the right way to handle something like libsodium is to have support for building targets using an external build system. I see that as a separate and independent feature from this proposal though. If you are interested in working on that feature I would love to discuss it more on a separate thread (I already mentioned it explicitly on another thread I am unable to find right now) -- it is a feature I would really like to see us have but don't have the bandwidth to tackle at the moment.</div><div class=""><br class=""></div><div class="">This proposal is very specifically targeting the desire to be able to write and build new C code as part of Swift packages, it is not designed to support importing large existing projects. While I do hope that it will feature creep over time to allow more and more C projects to fit within the supported conventions, I also expect that to be a long incremental process.</div><div class=""><br class=""></div><div class="">At this stage of the project, I would encourage looking at new proposals and features from a perspective of "does this add a useful new capability" and "is this in line with our goals" rather than "does this solve my immediate need X". </div><div class=""><br class=""></div><div class="">More comments in line...</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 3, 2016, at 12:17 AM, Drew Crawford 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class="">You keep referring to "'real' projects" as a proxy for the individual project you want support for; while there's a lot to be said for real-world use cases, I don't think this proposal's direction should be dictated by just libsodium.</div></div></div></div></blockquote><div class=""><br class=""></div>Nothing about this is reductive or specific to libsodium.<div class=""><br class=""></div><div class="">* libdispatch has a <a href="https://github.com/apple/swift-corelibs-libdispatch/blob/master/INSTALL" class="">build manual</a> that runs over 100 lines and involves checking out *7* other repos.</div><div class="">* Foundation (incl CoreFoundation) has a <a href="https://github.com/apple/swift-corelibs-foundation/tree/master/lib" class="">python-based build</a> system that runs to 1900 lines<br class=""><div class="">* libjpeg is "the" example of a C dependency in our documentation, and its build system includes such goodies as choosing a <a href="http://libjpeg.cvs.sourceforge.net/viewvc/libjpeg/libjpeg/configure.ac?view=markup" class="">memory manager</a> or configuring libpng.</div><div class=""><br class=""></div><div class="">And these are just the projects that *we* are associated with!</div></div></div></div></blockquote><div><br class=""></div>These are projects I would expect to be tackled with an "external build system" feature, not this proposal.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class="">There are C projects that would benefit from modularization, header auditing, and cleanups that Swift and swiftpm would bring to it. </div></div></div></div></blockquote><br class=""></div><div class="">Swift and swiftpm don't do anything of the kind. C developers do. All we can do is try to impose new requirements on C developers. And who is volunteering to implement those requirements?</div><div class=""><br class=""></div><div class="">It seems to me that if our new requirements are so amazing, it should be easy to convince a few projects to sign on to repackage. libdispatch and Foundation are *our* projects; the bar is so low we're practically cheating. Are they going to switch to this as their build system? I don't know who makes this decision, but it seems like an important question to ask.</div></div></div></div></div></blockquote><div><br class=""></div>While I think that "support libdispatch and Foundation" are good long term goals and useful reference points for what features are still needed to get there, it isn't the immediate goal here.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">No Swift project could be built with swiftpm when it was introduced without repackaging. I don't see why C support should be held to a different standard.</div></div></blockquote><br class=""></div><div class="">Because we're designing a package manager for the Swift language, not the C language. C has had build systems for decades. We're not going to just waltz in with a new standard for a 44-year-old language and everybody switches the next day. This is <a href="https://xkcd.com/927/" class="">https://xkcd.com/927/</a>.</div></div></div></div></div></blockquote><div><br class=""></div>We can all dream, right? :)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 2, 2016, at 8:11 PM, Zach Waldowski 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="">
<title class=""></title>
<div class=""><div class=""><blockquote type="cite" 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.<br class=""></blockquote></div>
<div class=""> </div>
<div class="">I almost couldn't disagree more. No Swift project could be built with swiftpm when it was introduced without repackaging. I don't see why C support should be held to a different standard.<br class=""></div></div></div></blockquote></div></div></div></div></div></div></blockquote><div><br class=""></div>I agree with Zach here. The purpose of the proposal is to add support for new code written in C designed to integrate with other Swift code. The merits of the conventions should be weighed about how easy it is to write that code, and what the implications for maintenance (on both the package manager and the code itself) are.</div><div> <br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">
<div class=""><blockquote type="cite" class="">And I do not see realistically how we are ever going to support a project like libsodium, except calling out to automake.<br class=""></blockquote><div class=""> </div>
<div class="">A potential solution (one of many possible) would look a lot like how people generate Xcode projects for C build systems today; hand-tuning config.h headers and such. I know many people who will go to ungodly lengths to avoid the inevitable nightmare automake causes in a source-distributed dependency.<br class=""></div>
<div class=""> </div>
<div class=""><blockquote type="cite" class="">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.<br class=""></blockquote><div class=""> </div>
<div class="">There are C projects that would benefit from modularization, header auditing, and cleanups that Swift and swiftpm would bring to it. C projects are massively disorganized because build systems are a ridiculous hodgepodge; we didn't be subject to that long tail of good and bad decisions.<br class=""></div>
<div class=""> </div>
<div class="">I don't think automake support would be a silver bullet at all, and contradict with many goals of swiftpm and llbuild to boot. Even targeting a really small subset of automake projects what liberties would unnecessarily complicate the project, and then there'd be the projects it doesn't support. (Oh? Wait? What version of the tools? Oh, from trunk? Oh, does the project take any liberties with its own organization? God help us when we start talking about C++…) <br class=""></div>
<div class=""> </div>
<div class="">"imaginary" is a reductive way of phrasing the problem space. You keep referring to "'real' projects" as a proxy for the individual project you want support for; while there's a lot to be said for real-world use cases, I don't think this proposal's direction should be dictated by just libsodium.<br class=""></div>
<div class=""> </div>
<div class="">Zachary<br class=""></div>
</div>
<div class=""> </div>
</div>
<div class="">On Sat, Jan 2, 2016, at 04:57 PM, Drew Crawford via swift-build-dev wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">Thanks for directing me to this, I missed it.<br class=""></div>
<div class=""> </div>
<div class=""><blockquote type="cite" class="">Most projects will not conform to these conventions.<br class=""></blockquote><div class=""> </div>
<div class="">Giggle. Kind of an understatement, no?<br class=""></div>
</div>
<div 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><br class=""></div>
<div class=""> </div>
<div class="">Let's take a look at how this package realistically builds:</div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>Here is how I would expect these things to be tackled:</div><div> </div><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<div class="">* It has tests ("make check")<br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>I don't have any particular plan for this one.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<div class="">* It has various --enable-foo flags<br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>I expect that eventually the package manager will grow some level of support for this kind of thing (similar to Cargo's "features" -- <a href="http://doc.crates.io/manifest.html#the-[features]-section" class="">http://doc.crates.io/manifest.html#the-[features]-section</a>).</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<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.<br class=""></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><br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>I expect that both of these would become possible with small enhancements to allow customization via the manifest file. Again, this is just the initial feature.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<div class="">* They build (also) on Windows. They're not changing how they're packaged for "SwiftPM, the Mac/Linux build system".<br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>I anticipate that we will eventually support alternative source layouts via customization in the manifest file (mostly to change where the sources are found, and the way headers are located and treated).</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<div class="">* Oh and this is cryptography code. Do you *really* want to touch it?<br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div>It is a non-goal of this proposal to support projects which "I don't want to touch".</div><div> <br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<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.<br class=""></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div><br class=""></div><div>I think your language is more polarizing than is due here, and I would encourage focusing on a technical argument rather than a judgement like "the entire value is debatable". This proposal will clearly allow packages to add small bits of C code which are used by other targets. Unless you believe that is incorrect (and if so, please present a technical argument for it), then to me that is a valuable capability (and if you disagree, then please present a technical argument for it).</div><div><br class=""></div><div> - Daniel</div></div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">
<div 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.<br class=""></div>
<div 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.<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><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:<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div class="">Happy 2016!<br class=""></div>
<div class=""> </div>
<div 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=""></div>
<div 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=""></div>
<div class=""> </div>
<div class="">Some TL;DR:<br class=""></div>
<div 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=""></div>
<div 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=""></div>
<div 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=""></div>
<div class=""> </div>
<div 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=""></div>
<div class=""> </div>
<div class="">Cheers,<br class=""></div>
<div class=""> - Daniel<br class=""></div>
<div class=""> </div>
<div class=""> </div>
<div class="">_______________________________________________<br class=""></div>
<div class="">swift-build-dev mailing list<br class=""></div>
<div class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class=""></div>
</div>
</div>
</blockquote></div>
</div>
<div class=""><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/10b469d346a6a3e62407ddcb992e64c157b547e1a0a28109a8064ada41237bbb/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3337323741745a7267364d22324175734d4151755349316146794f444b6a7435525a5555495145744257563376483f64636648475a777476647b667157436a6349413545564932344373335b464b69705161454963577537553831513f61757c4231464a4c687852383d22364542536864514a656241377e425d64637d41683c4268316f67307173426579726834675463357b6476663339384772524630346d2232464a69505e4a5a7d677d22364569497330553f694571725071316f4673665e63315d223247473a78747033764f6942785b4f657f603e646e4434363e635135355961377b413340784b675653773364375935655d23344/open" class=""><br class=""></div>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-build-dev mailing list<br class=""></div>
<div class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class=""></div>
</blockquote><div class=""> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OtwgWwWn2mvmck2XIGZZg64wEmoo4f4ILYe4SqMqwHpOK4lZtIvMfPQOw-2FDetbbuIQEq-2F7cT-2F9T59tIXnp-2B0CPBcOgOrCF4UR48Hn9mDShd-2BEe57UmU0fYQvSE1ARv5o7zKVLPO373r6EJmIJPONIrAZtJ5H2GdFZNzQT54XT5vPbHAwXqpri34zyiGrDQue0RCLlZdRhJfg2uGksNl8QW0djlOc-2BPZDn4Apx7mSO88-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<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=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AdkfTiApI80cNEyortTzHbERtY5det-2FDBvSxuhs4q2MTAacvM4gPJE45gIW8L9isB9iSC5Wvd7XS47eQanZVI6nvc7LWlKg2i18d2zn88WHSL3uTOr2vInLOeIUlXFg2E7omXBNBsvHWeGO1JP13xhwv6wbeTjJZVoPzDTVUH7PsLeuHCZLozobKO0jEkd8LW8zsnv5SuTaxtPWzRoBL6QI4IEYq8fCSQvWnOQ5HUEA-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<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=""></blockquote></div><br class=""></div></body></html>