On 01/03/2013 08:56 PM, Bob Friesenhahn wrote:
> 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 :-)
>
(About this: I was actually only joking about the confusing
/usr/ccs/bin/make vs. /usr/xpg4/bin/make "dichotomy").
> 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).
>
Of course; but then, the BSD systems are smart enough to call a
GNU make installed from ports or pkgsrc "gmake" rather than simply
"make". So, when I type "make" on those system, I expect to be
invoking BSD make rather than GNU make.
As for the SYSV-derived systems, if "make" does invoke the system
make, good; otherwise, the user running ./configure has GNU make
installed as his "default" make program, so the behaviour of the
system make is irrelevant for him. If the great majority of users
of an hypothetical vendor has its "make" command pointing to GNU
make, than the behaviour of the vendor make is to be considered
irrelevant, and that make is thus obsolete/unused in practice, no
longer worth supporting.
>> 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
>
No, because if the feature is not supported, a workaround kicks in
(with graceful degradation: if nested variables cannot be used, the
make verbosity can only be set at configure runtime, rather than
also overridden at make runtime).
> and request that the user specify MAKE if support for this feature
> is important.
>
ATM, it's not really important. It will become if we proceed with
my proposal, of course.
>> 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.
>
So, adjusting the roadmap:
- a loud warning in Automake 1.13.2
- an error in Automake 1.13.3, with a new temporary configure
option (or environment variable?) to make it non-fatal.
- same roadmap as before from Automake 1.14 onward.
Or even, skip the "loud warning" step and go immediately, right away
in 1.13.2, with a "fatal error that has to be explicitly quelled".
>>> 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.
>
The latter is not surprising, since Automake's INSTALL file is
merely a copy of the generic GNU one.
> If this variable was never mentioned by any instructional text,
> users can't be expected to ever use it.
>
This makes sense? Care to attempt a patch? I'm not going to
do it myself, I must admit.
Thanks.
Stefano
