GNU bug report logs - #7670
About make implementations that don't chain implicit rules

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: About make implementations that don't chain implicit rules
Date: Fri, 17 Dec 2010 23:52:17 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.