bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13349: [IMPORTANT] Could we just assuming support for make recur


From: Eric Blake
Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?
Date: Thu, 03 Jan 2013 14:34:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 01/03/2013 02:14 PM, Stefano Lattarini wrote:
>> So what's the verdict - do we (want to) support the user overriding
>> MAKE, and therefore document that in INSTALL?
>>
> Indeed, we should warn the user that if he configures an Autotools-based
> package with MAKE set in the environment (or passed on the command line),
> that he must use that same $MAKE to build the package; if this doesn't
> happen, semi-random (albeit unlikely) failures can crop up.

Okay, I'll whip up that autoconf patch.

> 
>> 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'?
>>
> Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message
> to report the "quirky" role of $MAKE (patches welcome).

I'll think about an automake patch to make it precious (at this point,
I'm thinking that the use of MAKE is too closely tied to automake, and
that autoconf itself has no business in setting MAKE as precious, only
documenting in the generic INSTALL that MAKE is often important because
of automake).

>  As for $MAKE
> becoming a precious variable, it cannot certainly hurt, but is not truly
> relevant either, since the user still has to invoke $MAKE himself, and
> configure cannot help him there.

Hmm, that goes back to one of the questions we asked about Automake-NG -
is it possible to write a generic makefile that merely forwards all
requests to gmake, and where all of the real magic of Automake-NG is in
GNUMakefile, so that even if the user types 'make all' they still end up
running 'gmake all' under the hood?  In fact, is it possible to write a
Makefile that compares the encoded settings of $(MAKE) set at configure
time, against the current value of $(MAKE) from the current make
implementation running the makefile, and which can re-execute and/or
loudly abort if there is a mismatch?

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]