[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27188: lex/yacc with subdir-objects and --disable-dependency-trackin
bug#27188: lex/yacc with subdir-objects and --disable-dependency-tracking broken
Sat, 17 Jun 2017 23:41:47 +0200
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Nick Bowler <address@hidden> writes:
> On 6/4/17, Mathieu Lirzin <address@hidden> wrote:
>> Nick Brown <address@hidden> 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?%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
> 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.
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37