[Top][All Lists]

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

[debbugs-tracker] bug#13760: closed (am__make_dryrun fails to handle GNU

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13760: closed (am__make_dryrun fails to handle GNU make -I option)
Date: Fri, 26 Apr 2013 18:26:02 +0000

Your message dated Fri, 26 Apr 2013 20:25:06 +0200
with message-id <address@hidden>
and subject line Re: [PATCH 0/3] dry-run: don't get confused by '-I' option
has caused the debbugs.gnu.org bug report #13760,
regarding am__make_dryrun fails to handle GNU make -I option
to be marked as done.

(If you believe you have received this mail in error, please contact

13760: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13760
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: am__make_dryrun fails to handle GNU make -I option Date: Tue, 19 Feb 2013 12:34:26 +0200 User-agent: Mutt/1.5.18 (2008-05-17)

After upgrading from 1.11.1 to 1.11.6 or 1.12.6, or 1.13.1 my
project's dist target stopped working. After some debugging,
the culprit turned out to be am__make_dryrun function that
mis-detects make dry-run mode (make -n) if make flags contain
a -I option with a path containing character 'n'. In my case,
flags come from the MAKEFLAGS environment variable which has
the following value:

-I ~/work/build -I/opt/qnx632/target/qnx6/usr/include

The MAKEFLAGS value as passed to the shell by make then becomes
(note the missing '-' in the first option -- that's documented
GNU make behavior):

"I /home/boris/work/build -I /opt/qnx632/target/qnx6/usr/include"

am__make_dryrun then goes ahead and check each word in this list
for the presence of 'n' and finds it in the path.

I've had some dealings with GNU make's MAKEFLAGS and the semantics
is quite convoluted. GNU make doesn't just store flags the way they
appeared on the command line. Instead, it translates, combines, and
rearranges them in a certain way. For example, GNU make will combine
certain one-letter options (including -n) and place them at the front
of MAKEFLAGS without the preceding '-'. For example:

make -n -k -j 2 foo=bar => "nk --jobserver-fds=3,4 -j -- foo=bar"

Generally, in GNU make, the -n option (or its aliases) will always
be translated and come in the first word of MAKEFLAGS. And the first
word in MAKEFLAGS is always one of the following:

1. Empty. If no "old" options (those that are combined in the
   first word) were specified but a new option was, then GNU make
   will add a leading space to the MAKEFLAGS, for example:

   make -j 2 => " --jobserver-fds=3,4 -j"

2. The "old" options combination (including -n), one letter per
   option, for example:

   make -n -k -j 2 => "nk --jobserver-fds=3,4 -j"

3. Command line variable assignment. If no options were specified
   ("old" or "new") but a variable assignment was specified, then
   the first word will be the variable assignment, for example
   (note that there is no leading space as in (2)):

   make foo=bar => "foo=bar"

So, based on this knowledge, for GNU make, all we need to do is
examine the first word in MAKEFLAGS. If it contains '=', then it
is a variable assignment, otherwise, we search for the 'n' character.

The complication is that we have to also support other makes (BSD,
Solaris). I have no idea about their MAKEFLAGS behavior.


--- End Message ---
--- Begin Message --- Subject: Re: [PATCH 0/3] dry-run: don't get confused by '-I' option Date: Fri, 26 Apr 2013 20:25:06 +0200
tags 13760 + patch

On 04/23/2013 11:12 AM, Stefano Lattarini wrote:
> Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13760>
> Hello, and sorry for the shameful delay.
> Boris Kolpackov wrote:
>> I think if we try to support all make flavors in a combined test,
>> things will get messy (my other idea was to resort to executing make if
>> MAKEFLAGS contains more than one word). Seeing that the majority is
>> probably using GNU make and we can do a really fast test for it, it
>> would be bad to resort to some pessimistic tests (like running make)
>> just so that we can support other makes.
> This sounds sensible.  I've taken this approach of using an "optimized"
> test for GNU make, and the more messy tests (in a "best-effort" fashion)
> for non-GNU makes.
> So, this series should fix automake bug#13760.  Testing and comments are
> welcome.  I will proceed to push in a few days if there is no objection.
Pushed now.  I'm thus closing this bug report.


--- End Message ---

reply via email to

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