Discussion: Hadrian's defaults

[Matthew Pickering]

My personal experience is that

1. -c doesn't work very well compared to ./configure for me and picks
up the wrong versions of alex/happy as installed by hadrian rather
than the ones provisioned by ghc.nix/. I have tried to avoid it anyway
after encountering some problems.
2. I have the impression that freeze1 being the default could be quite safe.
3. In my experience --share is too unreliable at the moment. I tried
using it for 2-3 days but it didn't seem ready.

The most friendly option to developers would be not building the perf
build by default but this has been repeatedly shot down in the past.

Cheers,

Matt

On Thu, Mar 14, 2019 at 3:20 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>
> I’ve been using Hadrian for a while. And I really like it. But I
> think, based on my experience and also the reading of the soon to be
> freshly reforged newcomers’ guide, that it could be greatly improved
> by changing the default of some of the more common options:
>
> The -c option should be the default. One of the cool thing about
> Hadrian is that it needs fewer steps to completion, as it knows how
> to run the boot and configuration script. It’s not always what you
> want, but if it isn’t, it should befall to you to specify it. The
> most common use is the default (-c is, for instance, used in the
> newcomers’ guide). The reverse flag could be --no-configure.
> --freeze1 should be the default. Ok, this one is harder. It’s
> almost always the right thing to call --freeze1 and forgetting it
> can have big consequences. So let’s make --freeze1 the default,
> add a flag --rebuild1 to force the rebuilding of stage 1. However,
> this requires an exception: if stage 1 was never built, we should
> build it, even without the flag --rebuild1.
> Eventually, the new --share option should be the default as
> well. But maybe the paint is a bit too fresh on this.
>
> If I missed something (other defaults which should be changed, or
> reason to keep the defaults as they currently are) reply to this
> thread.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs