Re: Discussion: Hadrian's defaults

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 [ https://github.com/snowleopard/hadrian/issues/457 ], who saw the arguments he passed to ./configure overwritten by Hadrian. This is surprising and unnecessary.

How about my reply in that it does not work. Configure isn't make.it never was. The whole point of configure is to perform configuration checks based on your environment. There are two real technical reasons that Hadrian cannot and should not run configure again on its own. 1) you cannot tell what arguments the configure was originally called with. Your assumption here is that everyone calls make with no arguments. This is simply not true. Yes the arguments are stored somewhat mangled in config.status but extracting them will prove very fragile. 2) Hadrian cannot restore the environment to what it was when configure was first called. Simple example CC=/foo/custom/compiler ./configure. Hadrain's -c by default would blow away this CC value and produce a config that would use something else. Giving me an abi issue that's harder to track down than the amount of effort it takes for someone to put -c. Configure by default has a much larger chance of producing invalid code than not having it by default. There is a very good reason why autoconf and automake are different. They have different goals. Hadrian is a replacement for make and shouldn't try to dictate what autoconf does. Tamar. On Tue, Mar 19, 2019, 08:42 Spiwack, Arnaud wrote:

On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery wrote:

...

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.

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.

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.

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 [ https://github.com/snowleopard/hadrian/issues/457 ], who saw the arguments he passed to ./configure overwritten by Hadrian. This is surprising and unnecessary.

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.

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.

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.

Best, Arnaud _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs