[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",
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
- Re: 'How makefiles are remade', (continued)
- Re: 'How makefiles are remade', Jim, 2004/04/20
- Re: 'How makefiles are remade', Noel Yap, 2004/04/20
- Re: 'How makefiles are remade', Jim, 2004/04/20
- Re: 'How makefiles are remade', Noel Yap, 2004/04/20
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade', Paul D. Smith, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade', Noel Yap, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade',
Noel Yap <=
- Re: 'How makefiles are remade', Noel Yap, 2004/04/21
- Re: 'How makefiles are remade', Paul D. Smith, 2004/04/21
- Re: 'How makefiles are remade', Noel Yap, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/23
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Message not available
- Re: 'How makefiles are remade', Jim, 2004/04/21
- Re: 'How makefiles are remade', Jim, 2004/04/20
- Re: 'How makefiles are remade', Noel Yap, 2004/04/20
- Re: 'How makefiles are remade', Jim, 2004/04/20