Re: Discussion: Hadrian's defaults

I have to admit I sympathize with Moritz's view. Since `-c` only 
"subsumes" the case where we call 'configure' with no extra env var or 
argument, and in the absence of a generic way to pass options to 
'configure' when using -c, I'd quite like to keep -c as a "cherry on 
top", for users who just need to boot and configure with the default 
arguments and for whom hadrian provides a way to save a few keystrokes. 
Just like Moritz, I'm not even sure it would make all that much sense to 
provide a way to pass configure arguments through hadrian, I have a hard 
time seeing a better UX than just running configure with the extra 
arguments directly and _then_ calling hadrian to start the build.

On 15/03/2019 14:35, Moritz Angermann wrote:
> Hi Arnaud,
>
>> On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud  wrote:
>>
>> On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel  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  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 
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ./hadrian/build.sh -j ...
> ...
>
> 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  && 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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England