[swift-build-dev] C dependencies

[Drew Crawford]

> I can see how this might be useful, but don't really see what it buys you if that just turns around and calls something as open ended as configure. Can you say more about why this is a good thing?

I think the premise is that structured formats are useful for a lot of problems. One example, the README has some interesting ideas about automatically checking license compatibility.  This presumes the license of a package can be statically inferred.  If the package metadata are defined in a Turing-complete language then that gets hard.  If it is YAML or something the problem is much easier.

The idea of someone defining their license as a function evaluation seems rather silly, but if it is legal then someone will do it. I also forsee security problems with this approach.  Somebody who wants to write a swift-packages.org <http://swift-packages.org/> search engine is about to find their life very painful.

Calling out to a real program seems more appropriate for a "so, you actually want to build this software" scenario rather than questions of basic metadata like the examples that appear in this documentation <https://github.com/apple/swift-package-manager/blob/master/Documentation/Package.swift.md>.

> I am generally a believer in "if you build it *better*, they will come". My goals here are not to encourage change by being a moral authority, but by simply providing a better solution to real problems than already exists, even for projects that don't care about Swift.

This argument concerns me.  What evidence would you cite that this actually works?

My frame of reference is e.g., Carthage (which IMO is better than CocoaPods), Ninja / CMake (which IMO are better than autotools).  It is my observation that the better build systems are dwarfed by the popular ones.

Further, I have some experience lobbying random projects to move to an obviously better buildsystem.  Historically it's always bit of a bikeshed, and generally a complete waste of time.  Is your experience here different?

I don't like it; I wish I lived in a world where the best build tool wins.  But the evidence suggests I might not live in that world, so I find arguments of the form "we will win because we have the best tool" concerning.

> If there are specific issues blocking this approach for "just getting it working" lets discuss that separately.

I'm going to open separate discussions as I run into problems.  But the preview is: I need to run a prebuild script of some kind in order to even get started.  I may just end up PRing something, since the discussion here seems to be wandering away from that part of the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151215/e6f909ff/attachment.html>