Hi Stefano, Eric, On 17 Nov 2011, at 00:27, Stefano Lattarini wrote: > On Wednesday 16 November 2011, Eric Blake wrote: >>> >>> + - At some point we were supporting some undetermined `broken make', as >>> + evidenced by having carried the following code since 2003: >>> + >>> + ## use @LIBLTDL@ because some broken makes do not accept macros in >>> + ## targets, we can only do this because our LIBLTDL does not contain >>> + ## $(top_builddir) >>> + @LIBLTDL@: $(top_distdir)/libtool \ >>> + ... >> >> By the way, such make implementations (that don't work with $(macros) in >> targets) exist: >> >> https://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html >> > This links says nothing about make not accepting macros in targets; it says > that using macros on the left side of a *macro assignment* is not portable: > > # Bad, not portable. > foo$(var) = bar > > # But this should be OK. > foo$(var): > @echo crating $@.
Right, and even when I wrote the dubious comment quoted above in 2003, other parts of libtool were still using macro expansions in make targets, so I think the whole thing is probably a red herring. Libtool has never fully supported any make that can't deal with macros in targets, and we've never received a complaint or bug report, which makes me think that if such a make exists, no one wants to use it with libtool, so we can safely ignore the whole thing. The NEWS entry I wrote for this commit is purely for future repo archaeology. >> At least IRIX and HP-UX vendor make fail to handle macros in the target. >> > Are you sure? I'm seeing this in the master branch of automake: > > $ grep -C1 '^$(.*) *:' lib/am/*.am > lib/am/check.am- > lib/am/check.am:$(TEST_SUITE_LOG): $(TEST_LOGS) > lib/am/check.am- @$(am__sh_e_setup); > \ > -- > lib/am/configure.am-if %?REGEN-ACLOCAL-M4% > lib/am/configure.am:$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps) > lib/am/configure.am-?TOPDIR_P? $(am__cd) $(srcdir) && $(ACLOCAL) > $(ACLOCAL_AMFLAGS) > -- > lib/am/configure.am-## Avoid the "deleted header file" problem for the > dependencies. > lib/am/configure.am:$(am__aclocal_m4_deps): > lib/am/configure.am-endif %?REGEN-ACLOCAL-M4% > -- > lib/am/lisp.am-## an empty target. > lib/am/lisp.am:$(am__ELCFILES): elc-stamp > lib/am/lisp.am-## Recover from the removal of $@. > -- > lib/am/subdirs.am- > lib/am/subdirs.am:$(RECURSIVE_TARGETS): > lib/am/subdirs.am-## Using $failcom allows "-k" to keep its natural meaning > when running a > -- > lib/am/subdirs.am-## bombs. > lib/am/subdirs.am:$(RECURSIVE_CLEAN_TARGETS): > lib/am/subdirs.am-## Using $failcom allows "-k" to keep its natural meaning > when running a > > ... but Ralf Wildnehues used to test automake somewhat regularly on both > IRIX and HP-UX, and to my knowledge never reported an error related to > the contructs above. > >>> + >>> + However, we've also had *many* cases of macros in targets for just as >>> + long, so most likely we never fully supported makes allegedly broken >>> + in this way. As of this release, we explicitly no longer support >>> + make implementations that do not accept macros in targets. >> >> I suppose we can resuscitate make portability if anyone complains loudly >> enough. We may want to also ask on the automake list if this is still a >> real limitation, or whether automake has given up on worrying about this >> as well. >> > See above. When my Internet comes back reliably and I can do more than just put mail in qmail's queue for the next time I have a bit of bandwidth, I'll make sure to test the HEAD of libtool master on the architectures I have access to, including both HP/UX and IRIX. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
