bug#27188: lex/yacc with subdir-objects and --disable-dependency-tracking broken

[Mathieu Lirzin]

Hello Nick,

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?%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