[Top][All Lists]

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

Re: Makefile Includes Remake ? / files .d dependencies

From: Paul D. Smith
Subject: Re: Makefile Includes Remake ? / files .d dependencies
Date: Fri, 9 Feb 2001 10:00:15 -0500

%% Peter Biechele <address@hidden> writes:

  pb> 1) I have used an implicit rule for producing %.d files from .c
  pb>    files like described in the GNU Make manual. This works fine,
  pb>    but it ALWAYS produces .d files, although I have changed only
  pb>    ONE c-file.

That shouldn't happen.  If it does, it means that your prerequisite
lists are too aggressive; you have the all the .c files as prerequisites
of all the .d files or something like that.  Without seeing the actual
rules, etc. you're using it's not really possible to advise you.

I suggest you look at the advanced dependency generation method I
describe on my web page below.  It's much better than the one in the GNU
make manual.

  pb> 2) I have split up the makefile into one main Makefile and 5
  pb>    included MAkefiles to seperate settings for paths, flags,
  pb>    etc. in seperate files. Now I want to make sure, if someone
  pb>    changes ONE of the Makefiles, I want to remake everything !
  pb>    This means I would like to call "make realclean" and then "make
  pb>    all", if one of the Makefiles have changed !! (This is because,
  pb>    if someone changes a define I have to recompile everything). Is
  pb>    there an easy solution ???

The only way to do this is the make all the makefiles prerequisites of
all the .o's.

Personally I think this is a Bad Idea; it means that any time someone
changes even a comment in one of those makefiles, your entire tree will
rebuild.  I suggest you simply provide a "realclean" rule and educate
your users about when it needs to be used.

My opinion is that people often try to have their makefiles do too
much.  A makefile should be a tool to serve the developer, not a yoke on
their backs.  Provide rules to do lots of useful things, and educate
your users about when they should be used.  If they're not capable of
understanding simple things like that, maybe they shouldn't be working
on the code in the first place... :)

 Paul D. Smith <address@hidden>          Find some GNU make tips at:            
 "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]