Re: 'How makefiles are remade'

[Noel Yap]

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", 
please?

> 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
>         $(SAVECMD)whatever

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.

Noel