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: Stefano Lattarini
Subject: Re: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Thu, 13 Jan 2011 20:04:14 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Thursday 13 January 2011, Ralf Wildenhues wrote:
> * 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*.
>
Well, I originally thought that the only real downside of having GNU
make as a requirement was that it should have to be obtained and
installed on the target system (unless it's already there in advance,
like on GNU/Linux) before an automake-using package could be compiled
and installed.

I thought I had dealt with this downside by showing how easy it is to
install GNU make -- by repeating some well-known truths ("GNU make is
a basic component of the GNU system, actively maintained and developed,
well documented, ...",  "GNU make is very portable, easy to compile,
and fully bootstrapping ..."), and by providing some IMO useful links
(e.g. Solaris, NetBSD and FreBSD packages providing GNU make).

Unfortunately, it turned out that ease of installation is not enough
for some users; see the excellent replies of Юрий Пухальский for more
information:
  <http://lists.gnu.org/archive/html/automake/2011-01/msg00071.html>
  <http://lists.gnu.org/archive/html/automake/2011-01/msg00075.html>

But after all this is the point of this discussion: probe the users
(well, at least those reading this mailing list) for problems and
contrary opinions I might not have thought of (or I might not have
even be *able* to think of!) by myself.

> *That* is what is needed to convince those who do consider requiring
> GNU make outright a regression.
>
But then, first I have to hear *why* they consider requiring GNU make
a regression (and who knows, I might even end up agreeing with them
at last, in some way or another).

> > > 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.
>
BTW, this is great news!  Sorry for not having told so before.

> > > 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,
>
I've never said it's worthless.  Please understand that my proposal is
all about "measuring" cost/benefit ratio of that feature: ct for the
automake developers of having to deal with make portability issues vs.
benefit for the users (and how much users, and for what reasons) of
having automake-generated Makefiles just work with generic vendor make
implementations).  The feature should be removed if that ratio is
deemed too high in the end.

> used by nobody, and nobody is interested in it.
>
IMHO the real questions are: How many people are interested in the
feature?  How much are they interested?  And especially, *why* are
they interested?

I found the replies of Юрий I linked above especially useful because
they answer the latter question in a clear, motivated way (at least
for what concerns him and the situations he have to deat with).

> 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.
>
Currently, the only motivated reason against my proposal I've read is
that of Юрий (which might be enough in the end, if we can conclude that
a high-enough number of users have requirements similar to his ones).

And to clarify, no, I don't think the "this is a dangerous slope" kind
of motivation is a sensible one; see:
  <http://lists.gnu.org/archive/html/automake/2011-01/msg00054.html>
for more info.

> > (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?
>
We should remove it if (and only if) the costs/benefits ratio is deemed
too high (and I'm not saying it necessary will).

> > > 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.)
>
I really didn't intend to ridicule the project, even if I see now
that my answer was formulated so badly that is was basically begging
for misinterpretation.  Quoting myself, I wrote:

 ``Well, the fact that it took me ~ 3 minutes to find it with Google
   is a good answer ;-)

   All kidding aside, is yours a serious question? ...''

So let me reformulate the above in a way that shouldn't (hopefully)
allow misinterpretation:

 ``I guess you're not speaking seriously, because that project is,
   in all pratical respects, dead and unmaintained, and never really
   took off either.  This is true independently of its qualities and
   merits, and is not intended as a criticism of its authors (after
   all, what's the motivation of working on a non-obvious software
   if nobody is using it?).

   That said, I have some "intrisinc" objections to that project too,
   but writing them down properly would require some time, which I'd
   rather not spend if you were just speaking tongue-in-cheek.''

And FTR, here are those objections (I ended up having to write them
down anyway at last):
  <http://lists.gnu.org/archive/html/automake/2011-01/msg00077.html>

> 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.
>
Unfortunately, he had apparently made such a good job on Automake that
no "living space" was left to this later project of his.  Too bad, the
codebase seems quite promising (at a first glance at least).

> 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.
>
Yes, it would, and rightly so -- but that would be the price to
pay for something that works *right from today*, and is ~ 99%
automake-compatible.

> > 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.
>
Yes.  And in the long (long long) term, it would even make sense to
"turn Automake into Quagmire" step by step, until that big-misfeature
is eaten away.  But again, having to cope with that misfeature today
(and likely for a long time afterwards) would be the price to pay for
something that works from today and is 99% automake-compatible (sorry
if I'm repeating myself, but I'd like to stress this point).

> > 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.
>
See my (alredy referenced above) reply at:
  <http://lists.gnu.org/archive/html/automake/2011-01/msg00077.html>
for what I really intended with "broken design" (this has been another
communication failure on my part; sorry).

> > 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.
>
OK, at least we agree on this (which is one of my main points BTW).

> >  - 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.
>
Yes (but a justfied fear IMO).  Anyway, on a second thought, that's not
really an objection against a Quagmire-like solution, since it would be
probably easy to just reuse the existing automake code and hand off the
compilation of shared libraries to libtool.

> >  - I think that keeping configuration and build steps separated is
> >    a very good idea.
>
Which, on a second thought, doesn't mean that some autoconf replacement
couldn't be implemented in GNU make, to take advantage of easier
parallelization (so maybe I was too categoric in my statement above
too).  That could be done in another project though (say, "mkconfig"),
and if that's done carefully, the hypotetical Quagmire heir could be
made to work both with mkconfig and with autoconf.

BUT I still think configuration and build should be done in separate
steps -- even more, by separated packages.

> I don't see any good reason for this, by the way.
>
You mean no good reason for keeping them separated?

> 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).
>
But appealing to that laziness was basically my motivation, and I stand
by it: "If it requires great efforts and offer little value, throw it
away".

Well, *I* perceived that it offered little value indeed; but some
users seem to disagree (offering real and clear motivations).
Hmm.  Now I'm somewhat torn myself ...

> Thanks,
> Ralf
> 

Regards,
  Stefano



reply via email to

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