On Wed, 2010-03-03 at 15:44 -0500, Adam Kellas wrote: > On Wed, Mar 3, 2010 at 2:45 PM, Adam Kellas <[email protected]> > wrote: > > It took me a while to figure out what was going on, since I > had some actual -p output with repeated and conflicting > variable settings which appeared to contradict what you say. > But it turned out I generated those using "make -n -p" instead > of "make -q -p". Since it's a recursive-make situation and > since -n does not suppress $(MAKE) recursion, I was seeing > conflicting settings derived from different Makefiles. Thanks > for clarifying. > > OK, the above is also at least partly wrong since -q and -n turn out > to have the same behavior wrt $(MAKE). So the net result is that "make > -q -p", in a recursive build setting, can result in multiple > conflicting values for variables with no well-defined order to > disambiguate. Oh well. I was hoping to do some useful re-engineering > with -p output but this may put a limit on that.
Well, there may not be a well-defined order WITHIN A GIVEN MAKE INSTANCE, but the entirety of the output of -p is printed by a given make instance before the next one is printed, so there is some order in which the databases themselves are printed and they are not jumbled together. And, you can determine which instance of make is printing by looking at the "Entering"/"Leaving" messages, for example. It would require some script fu to chop it up properly, but you could determine, for each instance of make, what the variables for that instance were set to at the time that make was going to run its rules (after it read in the makefile). _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
