bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Eric Blake]

[adding bug-autoconf, as owner of the source that becomes the generic
GNU INSTALL file]

On 01/03/2013 01:33 PM, Bob Friesenhahn wrote:
> On Thu, 3 Jan 2013, Stefano Lattarini wrote:
>>>
>>> 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.
> 
> If Automake-dependent packages are dependent on MAKE, then it seems that
> mention of MAKE should be added to the standard GNU INSTALL file (not
> just Automake's copy).
> 
> Previous to use by Automake in configure scripts, MAKE was an
> environment variable used for internal communication from a parent make
> process to a subordinate make process and set by make itself.

So what's the verdict - do we (want to) support the user overriding
MAKE, and therefore document that in INSTALL?  For that matter, should
autoconf (and/or automake) mark MAKE as a precious variable, so that it
gets listed in './configure --help', and so 'MAKE=gmake ./configure' has
the same results as './configure MAKE=gmake'?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature