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

[Nick Bowler]

On 2011-11-22 17:46 +0100, Stefano Lattarini wrote:
> On Tuesday 22 November 2011, Nick Bowler wrote:
> > This especially includes users who
> > have no idea that there's a difference between GNU make and the version
> > of "make" that is already on their system.
>
> Honestly, there are such users today?  I mean, almost every Unix newbie
> these days either:
> 
>  - installs a Linux distro, which comes with GNU make as the default 
>    make program (and we're also ignoring the fact that most such
>    users will install stuff only through the distro's package manager
>    anyway, not from sources -- and I don't blame them for this!);
>  - is using Mac OS X, which comes with GNU make as the default make;
>  - installs Cygwin (or possibly MinGW/MSYS) or on his Windows system,
>    thus getting GNU make as the default make in the process.
> 
> I expect a user of the *BSD systems (and even more of proprietay Unixes)
> will be learned enough to know the difference between the vendor make and
> GNU make.

This is probably true if the user installed such a system on their own
PC.  But people use computing systems that they did not install
themselves, especially with shared systems at schools.  At my alma
mater, the main computing environment was Solaris (thus "make" was
Solaris make rather than GNU make).  For many undergrads, this represents
their first encounter with unix-like systems.  We should strive to make
their experiences with free software on those systems a good one!

> That said, having some layer that would allow common "make TARGET" commands
> to re-invoke themselves with GNU make (maybe with a proper warnings) would
> be worthwhile; but this would *not* be done for the benefit of the newbies,
> rather to help out the experienced-but-distracted(-or-lazy) user.
> 
> > This is, I think, the single best way to encourage users to become more
> > involved in the free software community.  If the user can't easily build
> > a package, they won't test new versions and they won't test patches.
>
> Seriously, a user experienced enough to try out a patch will not
> have a problem understanding the difference the vendor make and
> GNU make, and to act consequently.

Maybe so.  On the other hand, if you search the web, today, you can
easily find instructions on how to apply patches.  About as easily as
you will find instructions saying to build a package using
"./configure && make".

Regardless, testing new versions is orthogonal.  If the user gives up
after failing to build from a release tarball they'll never even get to
testing patches.

> > (It's truly unfortunate that many popular GNU/Linux distros deliberately
> > make this more difficult than it needs to be, but I digress).
> > 
> > I have no doubt that using GNU make will make the the automake
> > maintainers' jobs easier.  It might even make the jobs of individual
> > package maintainers easier.
>
> See also:
>   <http://lists.gnu.org/archive/html/automake/2011-01/msg00091.html>

Yes, it is sad that many package maintainers fail to properly test their
build systems.  By the same argument, "GNU-make-requiring automake" is
never going to really support GNU make versions older then 3.82 because
maintainers won't bother to test with older versions.  Regardless, I
don't think this is a good reason to force non-portability on those who
take the time to test other make implementations.

> > But when a user building a free software package for the first time in
> > their life runs "./configure && make", and receives a spew of cryptic
> > messages about syntax errors or worse, I suspect that their first
> > reaction is not going to be "Whoops!  I should have run gmake instead."
> > More likely it will involve much more colourful language, and they will
> > be left with a bitter impression.
>
> OK.  So let's design the new automake to prevent this :-)  My above
> proposal of "automatic re-execution with GNU make" might help here.
> WDYT?

It's certainly an option.  If we go this route, I think we need, at the
very least:

 * 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).

> > Now, I'm not fundamentally opposed to the idea, but it has to be done
> > _right_.
> >
> Well, yes.  And I certainly value the issues you've raised (even if
> they are in no way show-stoppers IMHO).

We must weigh the costs against the benefits.  It's currently not clear
to me what the benefits actually are, to anyone other than automake
maintainers.

Currently, the benefits to automake maintainers is clear, there may be
some benefit to package maintainers (hopefully by making automake easier
to use), and there seems to be no benefit to users at all.

On the other hand, there seems to be a cost from the user's point of
view, and there will be an associated cost to package maintainers who
now need to educate their users about different make implementations.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)