GNU bug report logs - #27188
lex/yacc with subdir-objects and --disable-dependency-tracking broken

Previous Next

Package: automake;

Reported by: Nick Brown <brownn <at> Brocade.com>

Date: Thu, 1 Jun 2017 15:13:02 UTC

Severity: normal

Tags: confirmed

Merged with 9859

Full log


Message #14 received at 27188 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Nick Brown <brownn <at> brocade.com>, 27188 <at> debbugs.gnu.org
Subject: Re: bug#27188: lex/yacc with subdir-objects and
 --disable-dependency-tracking broken
Date: Sat, 17 Jun 2017 23:41:47 +0200
Hello Nick,

Nick Bowler <nbowler <at> draconx.ca> writes:

> On 6/4/17, Mathieu Lirzin <mthl <at> gnu.org> wrote:
>> Nick Brown <brownn <at> Brocade.com> writes:
>>> diff --git a/lib/am/lex.am b/lib/am/lex.am
>>> index d7ddc77..6357507 100644
>>> --- a/lib/am/lex.am
>>> +++ b/lib/am/lex.am
>>> @@ -23,6 +23,7 @@ endif %?MAINTAINER-MODE%
>>>
>>>  ?GENERIC?%EXT%%DERIVED-EXT%:
>>>  ?!GENERIC?%OBJ%: %SOURCE%
>>> +?SUBDIROBJ?	%SILENT%test -d $(dir $@) || $(MKDIR_P) $(dir $@)
>>
>> I suspect the '$(dir ..)' syntax is not portable.  Hopefully there
>> should be a alternative.  Can you look into it?
>
> $(dir ...) is most definitely not portable.  One alternative is to use
> $(@D), which is specified in POSIX and essentially works in every make
> implementation that I know of.
>
> However, there are still portability gotchas.  At least one implementation
> (dmake) supports $(@D) in principle but expands it in a not-quite-POSIX-
> compliant way.
>
> POSIX says that the expansion of $(@D) (and similar variables) does not
> include a trailing slash and expands to .  for the current directory
> (i.e., when the target name does not contain a slash).
>
> In dmake, the expansion of $(@D) (and similar variables) for the current
> directory is the empty string, otherwise the expansion contains a trailing
> slash.
>
> In cases where the difference matters, this can be worked around in the
> shell easily enough.  The difference matters if we adapt the above example
> because mkdir with an empty string will fail.  Something like this should
> be pretty portable (untested):
>
>   test x"$(@D)" = x || $(MKDIR_P) "$(@D)"
>
> Another way, perhaps even more portable, would be to do the splitting
> entirely in the shell, e.g., by using expr.

I have searched for similar MKDIR_P constructs in the lib/am files to
know what is the current practice, but I haven't found any.  I think it
might be reasonable to use $(@D) fornow.  In fact Automake is using it
in its own Makefile (see "bin/Automake.inc").

Besides the portability issue, we need to figure out if this bug-fix
doesn't bring some regressions (as suggested by the commit log sample of
my previous email).  I have run the test suite with the changes you have
suggested, and the test suite doesn't complain except for the "XPASS"
concerning the "t/lex-subobj-nodep.sh" test (the one I was refering too
in my previous email).  So this seems to look good, but this isn't
enough to commit it confidently.

I have discovered that this bug is a duplicate of #9859 for which you
have already sent a patch 2 year ago.  :)

Thank you for investigating.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




This bug report was last modified 5 years and 321 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.