<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=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">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?</div></div></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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 <a href="http://swift-packages.org" class="">swift-packages.org</a> search engine is about to find their life very painful.</div><div class=""><br class=""></div><div class="">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 <a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/Package.swift.md" class="">this documentation</a>.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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.</div></div></blockquote><br class=""></div><div class="">This argument concerns me. What evidence would you cite that this actually works?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: HelveticaNeue;" class="">If there are specific issues blocking this approach for "just getting it working" lets discuss that separately.</span></blockquote><br class=""></div><div class="">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.</div></body></html>