automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CRAZY PROPOSAL] Automake should support only GNU make


From: Ralf Wildenhues
Subject: Re: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Thu, 13 Jan 2011 09:29:30 +0100

* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 09:58:36PM CET:
> On Wednesday 12 January 2011, Ralf Wildenhues wrote:
> > The upsides are obvious.
> >
> If I'm not deluding myself, most of the contents of my proposal were
> aimed at showing why I believe that requiring GNU make is a reasonable
> and sensible policy, not to show what the advantages of such a policy
> would be -- quoting myself:
> 
>  `` And the gains in terms of maintainability, testability, and
>     possibility of optimization are obvious. ''

Sure.  You discuss the upsides of the strategy.  What I was asking for
is a discussion of the downsides of requiring GNU make, and arguing why
they are not a problem *for our users*.  *That* is what is needed to
convince those who do consider requiring GNU make outright a regression.

> > I was planing to introduce optional GNU make-specific code, and allowing
> > to let the user specify "my project requires GNU make anyway", which
> > would enable Automake to emit better code.  Arguably more complex than
> > requiring GNU make outright, but it wouldn't throw away all the make
> > portability work that exists in Automake.
> >
> Hmm... so you're telling me that "This code should be kept because it
> had been difficult to write it" is an acceptable rationale? ;->

No.  I'm saying that that portability is a *feature*.  You want to
remove that feature.  You need to bring solid reasons why the feature
is worthless, used by nobody, and nobody is interested in it.  And, of
course, why we should abandon the GNU Coding Standards mandate of only
requiring a small fixed set of Posix tools.

This thread has already shown that to not be true, judging from a couple
of the other answers.

> (BTW, that portability-related work has already and definitely served
> the purpose of making automake usage more widespread, so I don't think
> the efforts that went into it would ever be "wasted", even if the code
> they produced is going to be removed).

OK, so you're acknowledging that the feature serves a useful purpose.
Why should we then remove it?

> > But let me rephrase the critique in a poignant way: if you want to
> > require GNU make anyway, what is your rational to not use quagmire
> > instead of Automake?
> >
> You mean this?
>  <http://code.google.com/p/quagmire/>

Yes.  Please drop ridiculing in an otherwise sensible discussion, it
weakens your argumentation.  (It's also not the first time we've had
this discussion on this list.)

Tom Tromey (who, should you not know, has done more work on Automake
than anybody else), started quagmire, as a response to the idea that
GNU make should be required and exploited.  It is a rational answer
given the following thoughts: when you require GNU make, you

- want to allow your users to use GNU make to its fullest extent,
- can fix the problem of non-parallel configure tests,
- can avoid the slow m4+perl preprocessing steps.

* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 10:12:37PM CET:
> On Wednesday 12 January 2011, Ralf Wildenhues wrote:
> > Apart from that, if Automake requires GNU make, its users would rightly
> > demand that Automake ought to understand GNU make-specific constructs.
> >
> In which sense exactly?  If you mean in something like:
> 
>  bin_PROGRAMS = $(call my-macro,foo,bar)

Well, more likely, things like

foo_SOURCES = $(wildcard *.cc *.h)

which are asked for every few months.  We have a FAQ entry about it.

> then they should resign not to have it working for quite a long
> time I fear.

But that's something that would make me cringe if I had to use GNU make
anyway.

> After all, automake is just a pre-processor, not a GNU make superset.

But that mis-feature would be bug number One in this case.

> I stress this because I think that the only way not to have the
> hypotetical "automake2" end up as vaporware would be to start from
> the current automake implementation, ensuring we don't break the
> API nor regress the testsuite while we convert to gmake-only output.

* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 10:36:52PM CET:
> The "answer" I was speaking about would have been concerned with why I think
> that the quagmire *design* and *roadmap* are broken (even ignoring its "less
> than excellent" developement status).

Actually, I consider the design not so bad, but that's fairly irrelevant
to this discussion.

> Okay, at this point I can as well write that answer out summarily:
> 
>  - I want something that is backward-compatible with automake 1.11 as
>    much as possible (I mean 98/99% compatible), and that works from
>    "day 0".  Otherwise it won't stand any real chance of being used
>    by real-worls projects.

Well, there are counter examples (CMake, a couple of others) that show
that it is possible.  But it would be a large, not a small, effort, and
it is not clear that a new contester would stand a chance now.  One
cannot tell without trying though.

You are probably right in that many alternative build tools have not
taken off because they (necessarily) lacked compatibility, including
quagmire.

>  - I don't want to rewrite autoconf; with all its flaws, it rocks
>    and is incredibly mature ans well-written.

FWIW, I don't think quagmire, in the first iteration, wanted to replace
Autoconf at all.

>  - I don't want to rewrite libtool in GNU make.  The very idea of
>    trying to do so scares the hell out of me.

This is fear, not rational argumentation.

>  - I think that keeping configuration and build steps separated is
>    a very good idea.

I don't see any good reason for this, by the way.


I haven't yet see any argument in favor of "GNU make-only support"
versus "improvements for cases where GNU make can be assumed", that
would appeal to Automake users (rather than only to laziness of the
Automake developers).

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]