<div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Newcomers to autoconf-based ecosystems often add a rule to run configure to their Makefiles, as a "shortcut". At some time thereafter, they discover that there's a problem when configure alters the build plan make is executing. There's no sane way to integrate this properly if the build plan changes enough, even if configure is always the very first thing executed as part of the original build plan. This generally results in forcing make to abort after running autoconf, since trying to be more clever results in looping over configure. The only other way that works is arranging for 2-stage Makefiles where the outer one amounts to "configure && make -f Makefile.real". Which makes it noticeably more error-prone to tweak something and do a fast rebuild, since configure will often cause it to be a full rebuild instead. If you try to give configure dependencies so that it doesn't get re-run, you discover that it's dependent in some sense on its own outputs and again can cause loops.<div><br></div><div>Trying to integrate configure with hadrian runs the same risk, heightened by hadrian not using anything like Makefiles, so it would be even easier for it to either miss changes made by configure or end up looping on it. Or worse, the same with autoconf — or for ghc, the boot script which runs autoconf, among other things, and thus has even nastier risks in terms of missing important changes made thereby or causing loops.</div></div></blockquote><div><br></div><div> Aha! But is Hadrian doesn't use Make. And the shortcoming of Make which make autoconf necessary as a separate tools are ones that Shake fix. Making it a breeze to integrate a configure script without hassle.</div><div><br></div><div>I'll be honest, so far, so far, the thread doesn't have much convincing arguments in favour of keeping `-c`. The argument which I understand is Ben's in [ <a href="https://github.com/snowleopard/hadrian/issues/457">https://github.com/snowleopard/hadrian/issues/457</a> ], who saw the arguments he passed to ./configure overwritten by Hadrian. This is surprising and unnecessary.<br></div><div><br></div><div>But you have to realise what you are advocating for: the most typical workflow (not passing special arguments to ./configure) is the one which is special cased. We should rather take this as a challenge: how do we fix the limitations of `-c` so that it can be made the default; rather than giving up. A possibility would be to record the arguments passed to the configure script in a file, and make Hadrian pass these arguments to `./configure`. For instance.</div><div><br></div><div>I'd also like to impart a bit of urgency to this: we are breaking everybody's habit now, so now is the time to discuss changes. When we're used to the new build system and it isn't new anymore, it will become much harder to justify change.</div><div><br></div><div>By the way, on the default flavour: in addition to Ocaml's Dune, it appears that Bazel (Google's newish multi-language build system) also has the developers' build be the default. It's not enough data to establish that this default is the consensus. But I'm quite warming up to the position myself.</div><div><br></div><div>Best,</div><div>Arnaud<br></div></div></div></div>