[Top][All Lists]

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

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU m

From: Ralf Corsepius
Subject: Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?
Date: Tue, 22 Nov 2011 18:33:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 11/22/2011 06:04 PM, Stefano Lattarini wrote:
Hi Ralf.

On Tuesday 22 November 2011, Ralf Corsepius wrote:
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a "killer benefit" :-)

But now that I think about it, a GNU make-based rewrite might also offer
better extensibility (if we get the APIs right, that is), and that would
be a *great* improvement over the current situation, and one which would
benefit the whole user base (not only the maintainers).
Only Automake maintainers (a diminishingly-small percentage of the total
user base) care about how easy it is to maintain Automake. The users
care about how easy and reliable it is to build the software.

It would be useful to enumerate the user-visible benefits if Automake
can depend on using GNU make.
It's hard for me to imagine any, because keeping's free of
any proprietary make constructs (comprising gmake's) had been automake's

Not exactly; automake job's has been double-fold:

  1. As you say, helping in keeping's free of "proprietary" make
     constructs, *but only if the maintainer asks for it* (`-Wportability'
     or `--gnu').
  2. Offering well-tested and feature-rich implementation of common targets
     and checks -- while trying hard to remain compatible with portable
Mostly agreed, except that IIRC, 1. originally was different: Automake once switched to allow non-portable constructs, because the majority of automake's users is using linux+gmake underneath and does not care about portable make.
That said, apart from the fact that each generation of automake
maintainers at one point in his automake-carriere comes up with "switch
to gmake",
This to me is the real point. I feel history repeats.

my feel is automake must not use gmake because (in theory)
there should not be any to use gmake.

I don't understand what you're trying to convey here, sorry.
Sorry, fedora's broken thunderbird had corrupted my sentence:

Let me try to rephrase it:

If automake so far has been able to achieve its job, by not using gmake proprietary constructs in its Makefile.ins, then there should not be any need for automake to _now_ start using gmake-constructs in Makefile.ins.

Or simpler: So far, automake has not been using gmake, so why should it now start doing so?

Another question is if GNU make is really good enough to warrant this
sort of change.
Good point - gmake has a long history of "hickups" :-)

Care to elaborate on this?
Difficult to answer for me, because I am using automake with gmake (i.e. my works rely upon the subset of make-constructs automake uses) and do not exploit gmake. But I recall there had been massively broken gmake releases and releases with major functional changes, which had broken a lot.


reply via email to

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