Looking at the end of PR10996 [Take 2 for the *.7 files]

[Mark Mitchell]

>  > The use of $< is... touchy.  The fact that it depends on the name of the
>  > 'first' prerequisite can cause ordering changes to screw the Makefile,
>  > which is extremely undesirable.  Is there any reasonable way to avoid 
> this?
> 
> What you say is true.
> 
> In my defense, I did not modify any of the build steps that are already 
> present, just the dependencies.  Mark Mitchell wrote the generic rules 
> originally, so I cc:'d him to see if he has any input.

I think the value functions we're using are wrong.

Sure, $< means you have to keep the dependencies in the right order.

But, that's true for any target built by "compiling" a single file which
may itself include other stuff:

foo.o: foo.c foo.h bar.h
  $(CC) -c $<

I don't see any problem with remembering you have to put foo.c first in
that rule!  And if you forget, you'll know quickly enough, when your
program doesn't compile/link/whatever.

(Make rules are like functions in C.  You have to remember what order to
use when passing the parameters.)

I'd far rather maintain one rule with $< than ten rules without it!

I think we should be valuing the elimination of Makefile code
duplication much more highly than the non-use of $<.  Kelley's trying to
fix a situation where we have something like ten different rules for
building .info files, some of which use MAKEINFOFLAGS, some of which do
not, some of which honor BUILD_INFO, some of which do not, some of which
were putting things in docobjdir, some of which were not, etc., etc.

If we can collapse that into one rule, we've just improved the
reliability of our process and made it easier for front end maintainers
to keep up with changes in the central Makefile.  

That's a huge win.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC