Discussion: Hadrian's defaults

[Brandon Allbery]

I feel like you didn't read this completely. I used make as the example,
but hadrian is also a build system and will have some version of the same
problem: configure's dependencies are also its outputs. Hadrian might be
able to handle this, if it recomputes the entire dependency tree after
every operation — but any mistakes in the dependencies will lead to loops.

And none of this addresses the point that if configure is in any way
automatic, including as a separate initialization operation before
dependencies are computed, it's going to make life difficult for developers
who want to restart a build. Granting the viewpoint that says that
end-builder ease is more important than developer ease, but even there if
you make things too difficult for developers, a project that is already
short on developers may become even more short on developers and/or
developer time.

(I also think decisions like whether and how to run configure and/or the
build tooling should be part of my local configuration, because my own
needs will differ from others'. We already see this with devs who prefer
e.g. quick vs. perf builds.)

By far the safest approach is to keep configure separate.

On Tue, Mar 19, 2019 at 4:42 AM 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
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/7cc2dbf4/attachment.html>