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
