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

[Stefano Lattarini]

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