[adding automake list in CC] Hi Eric.
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 $@. > 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. Regards, Stefano
