This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Looking at the end of PR10996 [Take 2 for the *.7 files]
Mark Mitchell wrote:
> 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!
The difference I'm seeing is that the rule is separated from the list of
dependencies. As long as there's only one list of dependencies and it's
attached to the rule, that's great....
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.)
No, they aren't. Or at any rate they aren't when used properly.
Consider code like this:
FOO_OBJS = foo.o bar.o baz.o
$(FOO_OBJS): system.h
... (lots of other Makefile code) ...
foo.o: foo.c foo.h bar.h
$(CC) -c $<
*Now* do you see something wrong with having to remember to put foo.c
first?....
The implicit rules avoid this problem by being written properly as
pattern rules. Similar pattern rules would be just fine for this
situation (although it was pointed out that one case violates the pattern).
I'd far rather maintain one rule with $< than ten rules without it!
Well, this is certainly a "Your Mileage May Vary" case then! I find
myself in the opposite position. :-/
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.
Yeah, that's nice.
If we can collapse that into one rule, we've just improved the
reliability of our process
Nope.
and made it easier for front end maintainers
to keep up with changes in the central Makefile.
Yep.
That's a huge win.
If done wrong, it can be an *enormous* loss for maintainability of the
Makefile itself though. :sigh:
Repeat after me: Makefiles should not have order dependencies.
Particularly undocumented order dependencies. This is principle number
one of writing maintainable Makefiles which behave consistently.