%% gk <[EMAIL PROTECTED]> writes: g> I don't understand why make is trying to rebuild my Makefile.o, in g> the example below. It seems like my pattern rules must have g> screwed up the implicit rules or something. If I use 'make -r g> foo.c' I don't have a problem.
The first thing make does is try to rebuild all the makefiles it read in: this is the "auto re-exec" feature of GNU make. So, it wants to try to build "Makefile". Well, one of the builtin suffix rules is: .o: $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@ This is a suffix rule that says "you can build a foo from a foo.o using this command"; a link operation. So, make sees it can create a "Makefile" from a "Makefile.o". Well, how can it create a "Makefile.o"? It sees that there's also a suffix rule for that: .c.o: $(COMPILE.c) $(OUTPUT_OPTION) $< So, make knows it can build a "Makefile" from a "Makefile.o", and it can build a "Makefile.o" from a "Makefile.c". Well, how can it create a "Makefile.c"? Usually this is where the implicit chain ends, but you have added a new pattern rule: g> .PHONY: force g> %.c: force g> @echo 'rule: %.c' "target: $@" This rule says, "you can build any 'x.c', without needing any prerequisites at all, by running this command". I'm really unclear on what you're trying to do here; it seems like a very bad idea. But, regardless, make says "cool!". Now it knows how to rebuild your Makefile: first it runs that command you told it would generate a "Makefile.c", then it will run the compiler on it, then it will link it. If course, since the rule doesn't actually create a .c, the compiler fails trying to compile the .c. If you use -r, or you use ".SUFFIXES:" to remove the suffix rules, it works because make can't connect the dots: it doesn't know how to build a "Makefile" from a "Makefile.o", and if it did it wouldn't know how to build a "Makefile.o" from a "Makefile.c". g> I am trying to understand how implicit rules work so that I can: The above is derivable from the -d output. It requires a little bit of reading between the lines, but it's not too bad. g> 1. write my own rules which should take precedence over built-in g> rules and not break things All rules you write will take precedence over builtin rules; they are searched first and, if they conflict, rules you write will delete g> 2. avoid disabling all built-in implicit rules which may be useful g> if I have not pre-emted them in my makefile Personally I don't use the builtin rules ever. They're useful if you have a simple bit of code you want to build but _any_ moderately complex or longer-term project it's not worth it; remove the builtin rules and define your own. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make