[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7670: About make implementations that don't chain implicit rules

From: Stefano Lattarini
Subject: bug#7670: About make implementations that don't chain implicit rules
Date: Fri, 17 Dec 2010 23:52:17 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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
        (echo 'int main() {' && cat $<) > $@
        (cat $< && echo '}') > $@
  CLEANFILES = foo.d foo.c

  $ cat configure.ac <<'END'
  AC_INIT([foo], [1.0])
  AM_INIT_AUTOMAKE([foreign -Wall])

  $ 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
  @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
  @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
          (echo 'int main() {' && cat $<) > $@
          (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=\"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'
  $ /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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]