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

[Ralf Wildenhues]

* 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