[Top][All Lists]

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

Re: 'How makefiles are remade'

From: Jim
Subject: Re: 'How makefiles are remade'
Date: Wed, 21 Apr 2004 04:36:50 -0700
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

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

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



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

reply via email to

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