Severity: wishlist
Hello automakers.
Currently, automake is quite smart in catching and taking into account
possible chaining of implicit rules.
Here is a quite extensive example:
$ cat > Makefile.am <<'END'
bin_PROGRAMS = foo
foo_SOURCES = foo.e
.e.d:
(echo 'int main() {' && cat $<) > $@
.d.c:
(cat $< && echo '}') > $@
CLEANFILES = foo.d foo.c
END
$ cat configure.ac <<'END'
AC_INIT([foo], [1.0])
AM_INIT_AUTOMAKE([foreign -Wall])
AC_CONFIG_FILES([Makefile])
AC_PROG_CC
AC_OUTPUT
END
$ echo 'return 0' > foo.e
$ aclocal
$ automake -a
configure.ac:2: installing `./install-sh'
configure.ac:2: installing `./missing'
Makefile.am: installing `./depcomp'
# Let's see that the generated Makefile.in takes into account the
# implicit rules' chains.
$ grep foo_OBJECTS Makefile.in
am_foo_OBJECTS = foo.$(OBJEXT)
foo_OBJECTS = $(am_foo_OBJECTS)
foo$(EXEEXT): $(foo_OBJECTS) $(foo_DEPENDENCIES)
$(AM_V_CCLD)$(LINK) $(foo_OBJECTS) $(foo_LDADD) $(LIBS)
$ grep SUFFIXES:. Makefile.in
.SUFFIXES: .c .d .e .o .obj
$ egrep -A2 '\.[^.]+\.[^.]+:' Makefile.in
.c.o:
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF
$(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
--
.c.obj:
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF
$(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
--
.e.d:
(echo 'int main() {' && cat $<) > $@
.d.c:
(cat $< && echo ';}') > $@
# Now let's check that the produced Makefile really works as expected
# when it comes to a real build with a real make implementation.
$ autoconf
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
$ make
(echo 'int main() {' && cat foo.e) > foo.d
(cat foo.d && echo ';}') > foo.c
gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" \
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"foo\ 1.0\" \
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" \
-DPACKAGE=\"foo\" -DVERSION=\"1.0\" \
-I. -g -O2 -MT foo.o -MD -MP -MF .deps/foo.Tpo \
-c -o foo.o foo.c
mv -f .deps/foo.Tpo .deps/foo.Po
gcc -g -O2 -o foo foo.o
rm foo.d
$ cat foo.c
int main() {
return 0
;}
And here comes the problem. While the above example works correctly for
at least GNU make (tested with versions from 3.79 to 3.82), NetBSD make
(tested with the Debian port, pmake-1.111), and FreeBSD make (tested
with the Debian port from package freebsd-buildutils 8.0-1), it fails
with at least Solaris 10 XPG4 make, CCS make, dmake, and with Heirloom
make. For example:
$ /usr/xpg4/bin/make
make: Fatal error: Don't know how to make target `foo.c'
This happens because those make implementations fail to chain implicit
rules correctly; if the implicit dependencies are specified explicitly
in the Makefile, everything works as expected:
$ cat >> Makefile <<'END'
foo.c:foo.d
foo.d:foo.e
END
$ /usr/xpg4/bin/make
(echo 'int main() {' && cat foo.e) > foo.d
(cat foo.d && echo ';}') > foo.c
gcc -DPACKAGE_NAME=\"foo\" ... -c -o foo.o foo.c
mv -f .deps/foo.Tpo .deps/foo.Po
gcc -g -O2 -o foo foo.o
`all' is updated.
My question now is: could Automake become smart enough to make implicit
dependencies explicit in the generate Makefile.in, thus catering to such
make implementations? And if this cannot be done in the general case,
could automake help in some more specific, more predictable subcases?
Regards,
Stefano
