[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: |
Stefano Lattarini |
Subject: |
Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? |
Date: |
Thu, 03 Jan 2013 22:14:28 +0100 |
Hi Eric.
On 01/03/2013 09:40 PM, Eric Blake wrote:
> [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?
>
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.
> 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). 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.
Regards,
Stefano
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?,
Stefano Lattarini <=
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Nick Bowler, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Bob Friesenhahn, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03