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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7670 in the body.
You can then email your comments to 7670 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

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

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7670 <at> debbugs.gnu.org
Subject: Re: bug#7670: About make implementations that don't chain implicit
	rules
Date: Sun, 19 Dec 2010 11:58:50 +0100

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 11:52:17PM CET:
> Currently, automake is quite smart in catching and taking into account
> possible chaining of implicit rules.
[...]

> 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.

Yep.

> 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?

Making them explicit has the downsides that GNU make features for
intermediate files won't work any more (see info make 'Chained Rules',
although that describes implicit rules not suffix rules, to I'm not
quite sure any more which of those features also pertain to chained
suffix rules; it would be good to check that).

I'm wondering whether most Automake users are not more interested in
having them working, than having their package work with non-GNU make.
After all, today it really is hard to come by a system that doesn't have
GNU or some BSD make installed somewhere.

OTOH, do we generate such chained rules ourselves from internal rules?
That would be a bit worse, because in general we do have some users that
want non-GNU make to work.

Thanks,
Ralf

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7670 <at> debbugs.gnu.org
Subject: Re: bug#7670: About make implementations that don't chain implicit
	rules
Date: Tue, 21 Dec 2010 12:13:01 +0100

On Sunday 19 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 11:52:17PM CET:
> > Currently, automake is quite smart in catching and taking into account
> > possible chaining of implicit rules.
> [...]
> 
> > 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.
> 
> Yep.
> 
> > 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?
> 
> Making them explicit has the downsides that GNU make features for
> intermediate files won't work any more (see info make 'Chained Rules',
> although that describes implicit rules not suffix rules, to I'm not
> quite sure any more which of those features also pertain to chained
> suffix rules; it would be good to check that).
>
The part of the manual you pointed to seems relevant for chained suffix
rules, at least when explict dependencies are not mentioned:

  $ cat GNUmakefile <<'END'
  .SUFFIXES: .x .y .z
  all: a.z
  .x.y:
        cp $< $@
  .y.z:
        cp $< $@
  END
  $ : > a.x
  $ gmake
  cp a.x a.y
  cp a.y a.z
  rm a.y
  $ # check that make has removed intermediate file 'a.y'
  $ ls -l a.y
  ls: cannot access a.y: No such file or directory
  $ # check that make does not create intermediate file 'a.y' (even
  $ # if target 'a.z' depends on it) when 'a.z' is up-to-date w.r.t.
  $ # 'a.x'
  $ gmake
  gmake: Nothing to be done for `all'.
  $ # check that make can create intermediate file 'a.y' if
  $ # explicitly told to
  $ gmake a.y 
  cp a.x a.y

BTW, I also read this in the automake manual:

 ``Ordinarily, a file cannot be intermediate if it is mentioned in the
   makefile as a target or prerequisite. However, you can explicitly mark
   a file as intermediate by listing it as a prerequisite of the special
   target .INTERMEDIATE. This takes effect even if the file is mentioned
   explicitly in some other way.''

Thus, if the `.INTERMEDIATE' target does not cause problems with other
make implementations, we might consider using it to preserve GNU make
semantic for intermediate files, while also emitting explicit dependency
declarations for the sake of e.g. Solaris make (and other limited make
implementations).

> I'm wondering whether most Automake users are not more interested in
> having them working, than having their package work with non-GNU make.
> After all, today it really is hard to come by a system that doesn't have
> GNU or some BSD make installed somewhere.
>
Makes sense (but see above).

<offtopic>
 Maybe we might really start to consider dropping support for other make
 implementations (non-GNU and non-BSD) in a not-so-distant future?  That
 would greatly simplify maintainability and testability, with only a
 very minimal decrease in portability (since, as you noted, today it's
 really hard to come by a system without GNU or some BSD make installed
 somewhere).
</offtopic>

> OTOH, do we generate such chained rules ourselves from internal rules?
>
Yes, for Lex/Yacc; see also:
  <http://lists.gnu.org/archive/html/automake-patches/2010-05/msg00021.html>
  <http://comments.gmane.org/gmane.comp.sysutils.automake.bugs/4892>

> That would be a bit worse, because in general we do have some users that
> want non-GNU make to work.
>
:-(

> Thanks,
> Ralf
> 

Regards,
   Stefano

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

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	Юрий Пухальский <aikipooh <at> gmail.com>
Cc: 7670 <at> debbugs.gnu.org
Subject: Re: bug#7670: About make implementations that don't chain implicit
	rules
Date: Thu, 13 Jan 2011 19:46:38 +0100

I'm merging bug 7824 with this one.

If we can find a way to safely emit additional dependencies to help
these make implementation, then I am in favor of doing it.  (We can
wrap them in 'if !GNU_MAKE' if need be.)

Thanks,
Ralf

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7824 <at> debbugs.gnu.org
Cc: 7670 <at> debbugs.gnu.org
Subject: won't fix
Date: Sun, 22 Jul 2012 17:42:45 +0200

tags 7824 + wontfix
tags 7670 + wontfix
close 7824
close 7670
thanks

These bugs would IMHO be too expensive to fix, and anyway fixing them would
only bring a very marginal gain (as the issues only affects few vendor makes,
and only appears in unusual -- albeit admittedly fully legitimate -- setups).
In order not to keep the bug tracker cluttered up, I'm now closing these
reports, marking them as "wontfix".

Regards,
  Stefano

Previous Next

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