Discussion: Hadrian's defaults

Fri Mar 15 15:52:40 UTC 2019

Expanding on Moritz a bit:

configure creates a build plan, hadrian runs it.

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.

Really, don't try to conflate these; someone is going to end up very
unhappy.

On Fri, Mar 15, 2019 at 9:35 AM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi Arnaud,
>
> > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >
> > On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel <
> hvriedel at gmail.com> wrote:
> > I don't have the ticket number at my fingertips but it should be fairly
> easy to find.
> >
> > I'm afraid it doesn't appear to be. Could you share your arguments in
> this thread?
> This was the last one that lead to the current `-c` state:
> - https://github.com/snowleopard/hadrian/issues/457
> There is also
> - https://github.com/snowleopard/hadrian/issues/655
>
> if you look through the issues on snowleopard/hadrian and sort by comment
> frequency
> you'll likely find quite a lot of further discussion about not making
> configure and
> boot the default.
>
> >
> > On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
> > It's magically conflating two different phases with `-c`. The configure
> phase and
> > the build phase. Making this the default means it's always magic. I
> don't like magic!
> >
> > Unfortunately, I really don't understand what you are saying. What's
> magic about combining the phases?
>
> We have two phases:
>
> Phase 1: autoconf
>
>   This phase is essentially a code-generation phase, where specific
> templates are
>   instantiated to configure time value.  Which again can be split into two
> specific
>   subproblems:
>
>   - Generation of the configure script from the configure.ac and
> aclocal.m4 files
>     using autoconf.
>   - Generating code using the configure script by computing configure time
> calues
>     and filling those into the `.in` files producing the files that lack
> the `.in`
>     extension.
>
> Phase 2: building
>
>   This has been traditionally the job of make, and this is what hadrian
> should
>   replace.
>
>
> By subsuming the configure phase (by invoking ./configure) from hadrian we
> loose
> the phase distinction and if the `-c` flag is optional, users will *not
> even see*
> a flag that indicates that the system will run `./configure` for them.
> This is the
> magic I'm referring to and to which I strongly object.  If we can retire
> autoconf
> and do the whole configuration in hadrian, that story may change.  But as
> long as
> we are using an autoconf based configuration we should *not* run that
> magically.
> The `-c` flag is at least there to show that hadrian is explicilty
> instructed to
> run configure.
>
> ./configure supports its own set of flags, if hadrian subsumes those, we'd
> need
> some generic way of passing flags to ./configure, at which point I have to
> ask
> why do we do this in the first place and try to call ./configure from
> within hadrian?
>
> Unless you want to reconfigure ghc, or hack on it's autoconf part, you are
> likely
> going to run the following only:
>
> ./boot --hadrian
> ./configure <your flags of choice>
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ...
>
> the configure step is required, and should be explicit. That is where you
> configure
> your ghc build. Set host/build/target values, and other configure flags
> that
> influence how you want your ghc to be configure. Hadrian is there to build
> that
> configuration.  Mixing both may be convenient but hides the fact that
> there is a
> ./configure step.  I consider this hiding to be magic which is meant to
> benefit the
> user but hides what's really going on.  And again I don't like magic.
>
> Cheers,
>  Moritz
>
> PS: we also don't hide the `./configure` step in the usual `./configure
> <args> && make -j`
>     instructions when building other software, even though you could
> surely hack that into
>     your Makefile if you so wanted to.  Why start with ghc now?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

-- 
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/20190315/99addf5f/attachment.html>