Subject: bug#13760: [PATCH 0/2] am__make_dryrun fails to handle GNU make -I option

From: Stefano Lattarini <[email-masked]>
Date: Wed, 20 Feb 2013 14:07:51 +0100

Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13760>

On 02/19/2013 11:34 AM, Boris Kolpackov wrote:
> Hi,
Hi Boris, thanks for the clear and detailed report.

> 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'.
>
For the moment, I have exposed the bug you have reported in the
testsuite (see the two upcoming patches).  This issue shouldn't
be too difficult too fix; I hope I'll be able to cook something
in the next days, in time for the next beta for 1.13.2.

> 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.
>
This might be OK for GNU make:

  $ gmake -ki -I none -k -f- <<<'all:;@echo "$$MAKEFLAGS"'
  kI none -i

but not, e.g., for the FreeBSD and NetBSD make:

  $ bsd-make -ki -I none -k -f- <<<'all:;@echo "$$MAKEFLAGS"'
    -k -i -I none -k

nor for Solaris CCS make (note that this doesn't even support thr
-I option, though):

  $ /usr/ccs/bin/make -ki -k -f - <<<'all:;@echo "$$MAKEFLAGS"' 
  -ik

> The complication is that we have to also support other makes (BSD,
> Solaris). I have no idea about their MAKEFLAGS behavior.
> 
I have only a patchy knowledge too, but combining that with some
experimenting might be enough to find a fix

> Boris

Thanks,
  Stefano

-*-*-*-

Stefano Lattarini (2):
  tests: refactor/enhance tests about make dry-run mode
  coverage: expose automake bug#13760

 t/make-dryrun.tap | 123 ++++++++++++++++++++++++++++++++----------------------
 1 file changed, 72 insertions(+), 51 deletions(-)

-- 
1.8.1.1.754.gb3600c3