GNU bug report logs -
#27188
lex/yacc with subdir-objects and --disable-dependency-tracking broken
Previous Next
Full log
Message #14 received at 27188 <at> debbugs.gnu.org (full text, mbox):
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.