Discussion: Hadrian's defaults

[Phyx]

> 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 <arnaud.spiwack at tweag.io> wrote:

> On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery <allbery.b at gmail.com>
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/e1641ab1/attachment.html>