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

[Ralf Corsepius]

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 Makefile.am's free of
> > any proprietary make constructs (comprising gmake's) had been automake's
> > job.
> Not exactly; automake job's has been double-fold:
>
>   1. As you say, helping in keeping Makefile.am'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
>      make.
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.

Ralf