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
On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery 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.
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
Moritz Angermann writes:
> Hi Arnaud,
>
...
I second everything that Moritz said. Having spent countless hours
fighting other projects' "non-traditional" build systems in the past, my
heart fills with dread whenever I see a project trying to be "clever"
with autoconf. Inevitably such
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
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
Hi Arnaud,
Great to hear you've been using Hadrian for a while and like it!
As others have already pointed, -c used to be default. I personally was always
inclined to run boot and configure by default, because to me they seem like an
unnecessary complication on the way to the first GHC build
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
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?
On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann
wrote:
> On Mar 15, 2019, at 2:19 AM, Herbert Valerio Riedel
> wrote:
> On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud
> wrote:
> • The -c option should be the default.
> Very strong -1 from me on this one; I've been quite vocal on the Hadrian
> issue tracker early on and multiple times
On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud
wrote:
>
>- The -c option should be the default.
>
> Very strong -1 from me on this one; I've been quite vocal on the Hadrian
issue tracker early on and multiple times against having Hadrian invoke
./configure at all, even more so against
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.
>
I agree. But I also find it reasonable to make it so one won't accidentally
build a dev build when trying to make a release. (that being said, in the
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
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
14 matches
Mail list logo
