[jamming] Jam2.5 and precompiled headers
chrisant at windows.microsoft.com
Tue Feb 11 23:27:59 PST 2003
> > My private version's "+=" automatically copies the global value
> > first if appropriate, at least until someone can show me an example
> > where it would not be the Right Thing to do.
> That's an interesting. I never thought about this because I've never
> written a rule that would depend on the behavior of "on <target> +="
> either way. I usually keep the names used for target variables
> distinct from global variables.
> After thinking about it though, the behavior of your jam does not
> conform to my personal principle of least surprise. I think of the
> "on target" variables as living in a separate namespace, and would
> consider automatic "pollution" of this namespace an unexpected event.
That's interesting. The original Jambase doesn't conform to your
approach of using distinct variable names. Look at CCFLAGS, C++FLAGS,
HDRS, STDHDRS, for example. Each of these are used both as globals and
also as "on target" variables.
You basically just illustrated my point for me. Taking what you said to
its logical conclusion, Jam should disallow intersection of the global
versus target variable namespaces. That would be fine with me, though
it would entail tweaking a lot of rules.
I simply took the path of least resistance to fix the problem, based on
precedence that already existed in the stock Jambase.
The trouble is that today Jam explicitly allows namespace overloading,
and the stock Jambase even takes advantage of it. So I don't buy the
argument that Jam is designed for the global and target variable
namespaces to be independent or separate. Or, put another way, I don't
buy that the argument is still valid in the current state of Jam's
Besides, you might find it illuminating to take a closer look at the
exact values of for example $(HDRS) on targets. Part of what originally
sent me down this road was subtle cases where when I changed certain
headers Jam didn't rebuild the right things. After much debugging (and
sifting through -d9 output) I finally realized it was due to the problem
I've described. HDRS on the target was not quite the right value, due
to the ?= and += issue with the "on" keyword.
You might have cases lurking where "HDRS on target" is not set quite
right, and just not have noticed them yet. The only way I ever realized
was by sifting through -d9 output. Or your rules may have used another
tactic to fix the problem. Or the stock Jambase may have solved this
another way. I still haven't upgraded to Jam 2.4 much less 2.5.
More information about the jamming