[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13349: [IMPORTANT] Could we just assuming support for make recursive
From: |
Eric Blake |
Subject: |
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
signature.asc
Description: OpenPGP digital signature
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Bob Friesenhahn, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Bob Friesenhahn, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Bob Friesenhahn, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?,
Eric Blake <=
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Nick Bowler, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Bob Friesenhahn, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03