[Top][All Lists]

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

Re: 'How makefiles are remade'

From: Noel Yap
Subject: Re: 'How makefiles are remade'
Date: Wed, 21 Apr 2004 08:18:30 -0400
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

Jim wrote:

Some ideas I've toyed with - a make preprocessor... alternative makes - cook, hmm can't think of the others off the top of my head..

I've been saying this for several years now, but one day I'll learn cook :-)

Make is good... there have been several things I've wanted that I couldn't do quite as elegantly as I would have hoped...

Yeah, same here.  I've found that $(eval) goes a long way in reaching a middle 
ground, though.

$(foreach project,$(projects),$(project):$(CURDIR)/project)

declare for every project in the list a single dependancy which is that thing itself concated with current directory...

IME, using $(CURDIR) within a non-recursive make framework is not a good thing 
-- the build will depend on where make was invoked or the -C option.

One way I'd attack this is to have a makefile per project.  Each of these 
makefiles just does:

$(project): $(CURDIR)/project

If enough common code is created, they can be refactored into a separate 
makefile that's included by the project makefiles.

This is where the include-makefile macro comes in really handy.  Since it 
defines __FILE__, each project can now pass in different settings into the 
common makefile by doing something like:

  $(__FILE__).parameter := blah

okay what I have is a tree, much like any fairly complex tree, and like most it has come that some of the deeper branches are intertangled with branches closer to the root of the project,

It sounds more like a graph than a tree.

this means, that I have to invoke a seperate make in that root and forably

I couldn't extrapolate the meaning of "forably".  Can you explain, please?

scan, which loads a bunch of makefiles, does a bunch of expansions with a bunch of variables, and while make is somewhat surprisingly fast (even with all the convolutions), that branch-make is a bunch of useless checking if it's already been made... I'm sure at one time or another you've run into this, and while the tree could be restructured to flatten it out and untie its knots, there are often reasons for the branch to be in the place it is in...

A _small_ example directory hierarchy with minimal files and a brief explanation will 
help me understand better.  Also, could you explain what you mean by "branch", 

So I was reflecing on this problem - as I have for the past several months, and late last week realized that if I could just capture the targets being run...

    echo $@:$?

and the commands being run

I believe "make -n" does something like this.

into something like a makefile.cache, including all of these leaves nothing except bare targets and explicit rules.

This will be incomplete if not everything was built, but a "make -B -n" might 
do the trick.

No variables, no expansions, any point in the tree will include its parent's branches, and from any point in the tree the explicit dependencies down to header files that change that cause some other library to compile an object, and link its library can be discovered. Processing this master list (which I have managed to create) is much much faster than processing each make in each directory to check to see if something might have changed.... and even with the lost few days, if it had worked, the seconds gained for the sum of all makes, plus the reduced time of tracking down which library wasn't quite in the tree in the right place from some particular branch to know about and to make it, will more than cover the lost time...

I see.  It sounds like you want something like "make -B -n >Makefile.cache" and, so long 
as none of the makefiles have changed, do "make -f Makefile.cache".  Is this correct?

Of course, you'd want to do this all in one step such that make itself will 
check Makefile.cache's dependencies, rebuild it if necessary, include it, then 
re-exec.  Is this correct?

But, after fighting with odd behaviors, I boiled it down to a much simplified example that demonstrates exactly what I'm doing (including the commented out remake, which can be used to demonstrate the correct sequence of loading the included portions), and the only problem with THIS, is that is results with /bin/false - which even when all is made well and correct, the make returns with an error, also, I have approx 76 branches that get processed, and I end up with one tall stack of makes all ready to return either the error from make, or the /bin/false when they get around to it, since I cannot let them continue to process remaining targets, as the original make does not have the correct makefile actually loaded....

I think this is the part that's way too complicated and another solution (eg "gmake 
-B -n") should be found.


reply via email to

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