Hello Nick, Nick Bowler <nbow...@draconx.ca> writes:
> On 6/4/17, Mathieu Lirzin <m...@gnu.org> wrote: >> Nick Brown <bro...@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
