[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'How makefiles are remade'

From: Paul D. Smith
Subject: Re: 'How makefiles are remade'
Date: Wed, 21 Apr 2004 08:19:27 -0400

%% Jim <address@hidden> writes:

  j> Paul D. Smith wrote:

  >> Yes it is, if you write it correctly.

  j> (sorry, this is such an attacking statement...)

Sorry; I didn't mean it like that.  I just meant you have to write it in
a very specific way ("correctly") or it won't work.

The reality is that GNU make is not designed to behave the way you want
it to behave.  It's designed to work like this:

 1) All makefiles are read in (the main makefile, included makefiles,
    stuff in MAKEFILES, etc.)

 2) Make examines every makefile that it read in and tries to rebuild

 3) If the result of step #2 is that _any_ of the makefiles were
    rebuilt, make re-execs itself.

 4) If we get here, no makefile was remade, so continue with normal make

Making it work the way you want (if I understand you correctly), where
steps 2 and 3 are performed in a loop so that the re-exec happens
immediately when each makefile is rebuilt instead of after all the
makefiles are rebuilt, is simply not the way make is designed.  Trying
to make it behave this way is extremely tricky, as shown by my example.

  j> The correct way being that a makefile includes one and only one
  j> other makefile?  I mean sure, if the documentation didn't say if
  j> ANY change, then the make is restrated

That's true.

  j> (one would assume that to imply at the end of the rule which
  j> generates a changed makefile

That assumption is incorrect and not justified by any text in the
manual.  I think this is a case of reading into the docs what you
expected to find.

In fact, I think the documentation is quite clear on this point.  This
is the second paragraph in the section "How Makefiles are Remade", which
is where this entire feature is described:

     To this end, after reading in all makefiles, `make' will consider
  each as a goal target and attempt to update it.  If a makefile has a
  rule which says how to update it (found either in that very makefile or
  in another one) or if an implicit rule applies to it (*note Using
  Implicit Rules: Implicit Rules.), it will be updated if necessary.
  After all makefiles have been checked, if any have actually been
  changed, `make' starts with a clean slate and reads all the makefiles
  over again.  (It will also attempt to update each of them over again,
  but normally this will not change them again, since they are already up
  to date.)

I honestly don't see any room for misinterpretation here.  If there is
confusion please let me know; now is a good time to make changes to the

  j> I still have to submit this as a documentation bug, that it is
  j> unclear that make lacks the functionatilty to cleanly reload
  j> product include files) And yes, when building a project and
  j> spontanseously having .d files populating the direcotyr, these
  j> being included, I would not assume that these should be done... but
  j> again, that would typically be under the section of "Updating goal
  j> targets..." when producing object and as a by product the
  j> dependancies thereof.  but when in the "Updating makefiles...."
  j> section (as indicated when running with a -d option) I would think
  j> that it would be reasonable to restart the make at the end of each
  j> target which causes an include to change.

In the vast, vast majority of cases this would be extreme overkill.  If
you had a directory with 100 C files in it this would involve
potentially 100 re-execs of make, when only one was needed.

The situations where you need this kind of "chained include" are, at
least in my experience, very rare.

I think Noel has it right here: maybe if you step back and give us a
higher-level view of what you are trying to do we would better
understand the problem and could perhaps provide alternative solutions.

  j> Okay.  That $(warning reading Makefile) gave me a good
  j> idea... There was definatly some question of order... it seems the
  j> last included is the first checked, unless that depends on the
  j> first included....

True.  There is actually no defined order in which the included
makefiles are checked, so you cannot make any assumption about that
unless, as you say, you put in explicit dependency information.  Also
note that if you use -j you could get multiple makefiles rebuilt at the
same time.

  j> Maybe you could chalk this up to a documentation bug, it says whenever 
  j> ANY included makefile is read, it reloads,

Correct.  But that doesn't say, nor imply, that it reloads immediately
when the makefile is reloaded.  In fact, as the complete text I quote
above makes quite clear it does _NOT_ reload until all makefiles have
been checked and possibly remade.

 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]