Re: Why does make try to build Makefile.o?

[Paul D. Smith]

%% gk <address@hidden> 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 <address@hidden>          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