So, to summarize the main points so far:
* From RMS: it would be a good idea to start requiring GNU make in
just one or two GNU packages, and see how many users complain, and
how loudly. My follow-up on this: we could do this experiment by
being even more conservative, and have one or few GNU packages
offer distribution tarballs requiring GNU make by default, while
continuing (for a while at least) to also offer distribution
tarballs that only require portable make. Ideally, the download
links for such "compatibility tarballs" should not be accessible
from the package's web pages directly, but only referenced in the
INSTALL file of the "new-style tarballs".
Now we shouldfind one or two package maintainers willing to
submit themselves to this experiment ...
* Paolo Bonzini pointed that a backward-incompatible "Automake 2"
might propagate the past bad reputation of the autotools w.r.t.
backward-incompatibility. So the new project I'm proposing should
be a fork of automake, with a repository and name of its own.
I propose "Automire" as the name, to give credit to the Quagmire
attempt, while retaining the `am' namespace. So I guess I should
open a new thread to discuss the detail of such forking... any
idea of what would be the better GNU list(s) to do so?
* Nick Bowler pointed out that my ideas of "Unix newbies" was quite
wrong in practice, as many of them won't be GNU/Linux newbies, and
might instead be exposed to other Unix variants in corporate or
educational environments. So the default "make" program they'll
use might likely not be GNU make, whose existence they might even
ignore. My follow-up on this was a proposal to create some layer
that would allow common "make TARGET" commands to automatically
re-invoke themselves with GNU make (maybe with a proper warning)
when possible.
So, as Nick suggested, automire should make it easy to:
- have autoconf tests to find a working GNU make;
- put GNU make logic in GNUmakefile, so that other makes do not
try to parse it, and GNU make users don't have to care;
- put stubs in the Makefile for all common targets that will
then re-invoke GNU make.
- allow package maintainers to easily define new stubs for their
custom targets (bonus points: make this automatic).
* Paul Smith suggested that it would be worthwhile to have an explicit
list of capabilities that automire will require from GNU make. I
agreee with him. That list could be written later, though, once
automire makes some real use of advanced GNU make features.
* Through a sub-discussion between me and Ralf Corsepius, I came to
conclude that having automire taking advantage of more GNU make
features could help in making GNU make itself better, by finding
(and hopefully fixing) lurking bugs and/or usability problems.
Regards,
Stefano
