Re: 'How makefiles are remade'

[Jim]

Noel Yap wrote:

> Can you state what you want to do in development process terms, rather 
> than makefile implementation terms, please?  Maybe there's another 
> solution that doesn't involve extremely complicated makefiles (maybe it 
> doesn't even involve make ;-).

Well okay, I'll consider how much after 'in the beginning there was the 
void' I can begin...

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..

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

$(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...

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, this means, that I have to 
invoke a seperate make in that root and forably 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...

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

into something like a makefile.cache, including all of these leaves 
nothing except bare targets and explicit rules.  No variables, no 
expansions, any point in the tree will include its parent's branches, 
and from any point in the tree the explicit dependancies 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...

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....

this results in what 156 or so lines of Make exiting reporting that it's 
exiting, and the status... 2 lines each - which way scrolls off the 
actual cause of the ending of make.

Some other things I had wanted from make was to be able to redefine 
variables as the result of having built a target, but that would 
essentially be echoing those new values into a makefile and reloading - 
oh but wait, that doesn't happen :)  Or if it does, it's only after all 
targets are processed with now inaccurate defined values.



SO - that was really all about using make and the philosophy of make to 
accomplish tracking dependant sources, objcts, final products in a 
project tree which may have multiple distinct roots (well that's the 
next step to cover, just need one tree to work now)... really all I'm 
trying to do is produce from source to end product in the most efficient 
manner possible... but aren't we all? :)  And you're right, much like 
dificinecies in other products such as CVS's lack of directory 
versioning for moving and renaming purposes, perhaps the solution is not 
in make but in something that I have not found yet.

I have produced a robust system using makefile scripting defining only 
the most basic elements of a project within each branch - and I'm sure 
there are 100s of such implementations - I mean make itself even has 
builtin rules, if those match your development environment, it's easy to 
produce product from source...

But I'm teetering between windows and linux, and other platforms, and 
didn't really want to take the time to write my make tool, which noone 
would use, but which would amuse me for a time....

By the way - the thing I'm playing with at the moment is

http://sack.sf.net
http://www.sf.net/projects/sack

> Thanks,
> Noel
>
> Jim wrote:
>
> > If there was just a way to end make with the last executed make's 
> > status (including when that make ends with success... otherwise all 
> > other targets are processed again, but with an invalid state, since 
> > those files which were modified were not reloaded) that would be 
> > great, and or to force a reload...