GNU bug report logs - #13349
Could we just assume support for make recursive variable expansion unconditionally?

Previous Next

Full log

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org
Subject: Re: [IMPORTANT] Could we just assuming support for make recursive
	variable expansion unconditionally?
Date: Thu, 3 Jan 2013 13:56:35 -0600 (CST)

On Thu, 3 Jan 2013, Stefano Lattarini wrote:
>>
>> How would you know the make program that the user will actually use?
>>
> Assume it is either the default one, or that $MAKE is passed to
> configure.  Automake-generated configure code has been doing this
> assumption since a long time, so nothing new here (albeit the
> situation is clearly suboptimal).
>
>> Some systems may have three or four 'make' type programs installed.
>>
> Ah, lovely Solaris :-)

And BSD and SYSV-derived systems.  GNU/Linux is about the only system 
where 'make' is almost certain to be GNU make (and maybe modern OS-X).

> Nope, no such check from us.
>
> * Not in configure.  Here is how Automake-generated configure code
>  looks for the make program (slightly tweaked for readability):
>
>    am_make=${MAKE-make}
>    echo -n "checking whether $am_make supports nested variables... "
>    if ${am_cv_make_support_nested_variables+:} false; then :
>       echo -n "(cached) " >&6
>    else

It seems like the above should be changed to produce an error and 
request that the user specify MAKE if support for this feature is 
important.

> That's why I proposed, in my second point (which you have elided,
> apparently) a runtime probe to be added to *every* configure script
> generated from a AM_INIT_AUTOMAKE-using configure.ac:
>
>  - Enhance the checks in the AM_SILENT_RULES macro to print a loud
>    message at configure runtime if the make implementation on the
>    system isn't able to grasp recursive variable expansion, telling
>    the user to report the situation to our upstream (bug-automake).
>    This is of paramount importance for us to know how the situation
>    "in the wild" really is.  In the past, Autoconf did something
>    similar to ensure the presence of shell functions in all the
>    shells worth supporting.

Most users ignore configure output unless configure fails.

>> If GNU make is installed on the system and called 'gmake' but
>> the user types 'make' and 'make' does not support recursive
>> variable expansion, what will happen?
>>
> Nothing, since configure does not look for gmake, but only for
> ${MAKE-make}.  If the user exports "MAKE=gmake" and then runs
> "make", well, he's asking for troubles -- and he'll get them.
>
> Hope that clarifies the matter a little.

It is a problem that MAKE is not mentioned in the standard GNU INSTALL 
file, or in Automake's own INSTALL file.  If this variable was never 
mentioned by any instructional text, users can't be expected to ever 
use it.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.