<div dir="auto">Agreed, I was also an opponent of -c as the default, and as you pointed out it only works for the case where the default is used. But even if the defaults are used it is still harmful to do it automatically as the user's environment could have changed resulting in different configure output if you automatically rerun it. <div dir="auto"><br></div><div dir="auto">Not only isn't there a sane UX for this, there isn't even a safe way to do this. <br><br><div data-smartmail="gmail_signature" dir="auto">Sent from my Mobile</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019, 16:51 Alp Mestanogullari <<a href="mailto:alp@well-typed.com">alp@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<div class="m_-9150325780560724620moz-cite-prefix">On 15/03/2019 14:35, Moritz Angermann
wrote:<br>
</div>
<blockquote type="cite">
<pre class="m_-9150325780560724620moz-quote-pre">Hi Arnaud,
</pre>
<blockquote type="cite">
<pre class="m_-9150325780560724620moz-quote-pre">On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud <a class="m_-9150325780560724620moz-txt-link-rfc2396E" href="mailto:arnaud.spiwack@tweag.io" target="_blank" rel="noreferrer"><arnaud.spiwack@tweag.io></a> wrote:
On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel <a class="m_-9150325780560724620moz-txt-link-rfc2396E" href="mailto:hvriedel@gmail.com" target="_blank" rel="noreferrer"><hvriedel@gmail.com></a> 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?
</pre>
</blockquote>
<pre class="m_-9150325780560724620moz-quote-pre">This was the last one that lead to the current `-c` state:
- <a class="m_-9150325780560724620moz-txt-link-freetext" href="https://github.com/snowleopard/hadrian/issues/457" target="_blank" rel="noreferrer">https://github.com/snowleopard/hadrian/issues/457</a>
There is also
- <a class="m_-9150325780560724620moz-txt-link-freetext" href="https://github.com/snowleopard/hadrian/issues/655" target="_blank" rel="noreferrer">https://github.com/snowleopard/hadrian/issues/655</a>
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.
</pre>
<blockquote type="cite">
<pre class="m_-9150325780560724620moz-quote-pre">
On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann <a class="m_-9150325780560724620moz-txt-link-rfc2396E" href="mailto:moritz.angermann@gmail.com" target="_blank" rel="noreferrer"><moritz.angermann@gmail.com></a> 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?
</pre>
</blockquote>
<pre class="m_-9150325780560724620moz-quote-pre">
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 <a href="http://configure.ac" target="_blank" rel="noreferrer">configure.ac</a> 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?
</pre>
<br>
<fieldset class="m_-9150325780560724620mimeAttachmentHeader"></fieldset>
<pre class="m_-9150325780560724620moz-quote-pre">_______________________________________________
ghc-devs mailing list
<a class="m_-9150325780560724620moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a>
<a class="m_-9150325780560724620moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank" rel="noreferrer">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
<pre class="m_-9150325780560724620moz-signature" cols="72">--
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, <a class="m_-9150325780560724620moz-txt-link-freetext" href="https://www.well-typed.com/" target="_blank" rel="noreferrer">https://www.well-typed.com/</a>
Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England</pre>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>