[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging Make
Paul D. Smith
Re: Debugging Make
Thu, 25 Mar 2004 14:40:25 -0500
%% Ken Smith <address@hidden> writes:
ks> Sometimes, errors like this are hard to detect. I would like to
ks> be able to run my makefiles through some processor (make -someflag
ks> > makefile.out) and see what make thinks I'm telling it.
You can use the -p option: make will print out its entire internal
database. That would catch the situation with the variable being set or
The output, however, is dumped from make's internal hash tables so it is
in no order and in particular it has no relationship to the order in
which it appeared in the makefile (although the filename and linenumber
where the rule or variable was read in _IS_ shown in the output).
ks> here's more straightforward example.
Heh. Actually this is a much _LESS_ straightforward example.
ks> After running through the debugging feature I'm talking about,
ks> makefile.out would contain the following.
Why would that be the output? That output is completely wrong, and as
such is worse than useless :(. The correct output would be:
And, this is exactly why what you are asking for is very difficult...
difficult enough to probably not be worth it. The only way to do what
you're asking would be to read the entire makefile once in "normal"
mode, then read it again in a special mode that wrote out the expansion
of the variables based on the results of the first parse, but without
actually performing any of the actions.
Remember that make doesn't resolve recursive variable settings until
they're used. So, when make reads in the line:
it does _NOT_ resolve the value of "a". Instead, that value is resolved
when $(b) is expanded. Between the time you write "b=$(a)" and the time
b is actually expanded, a could have a completely different value... as
it does in this example.
I have on my TODO list an "elaborated makefile" output which would do
part of what you want. It basically would expand the "immediate
expansion" parts of the makefile (see the GNU make manual for a
definition) and write them back out with line numbers, etc. to aid in
debugging. But it wouldn't resolve the above problem.
Paul D. Smith <address@hidden> Find some GNU make tips at:
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist