From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-25 03:45:05
Mark Elston wrote:
> This is really cool.
> BTW, now that I am apparently getting past the introductory newbie
> user stage is there any docs on the architecture or design that
> would help me get up to speed on how this is put together?
Alas, not very much. We used to have architecture.html document, but it's
very, very out of date.
> I would
> like to help out with the development but have *soooo* many
> questions when I look at the jam code that I feel I must be missing
> something obvious. I expect that, at some point, things will just
> 'click' and I will begin to see how this all fits together but
> right now, except for some obvious pieces (tools/msvc.jam,
> gcc.jam, etc).
I understand the problem. I'll try to document this better, maybe even now.
> Even the comment below that the entry point for conditionals handling
> is in evaluate-conditionals in build/property.jam is only partially
> helpful. It would really help to have a better picture of how this
> jam function (as an example) gets called, where it gets called from,
> what its parameters are, how they were generated, etc.
> For example, I started by looking for the string 'evaluate-conditionals'
> in jam_src but couldn't find
Looking in "jam_src" is not going to help ;-) Most of Boost.Build logic in in
> These two belong to the property-set.evaluate-conditionals rule which
> does not call property.evaluate-rules:
> ./build/property-set.jam:173: rule evaluate-conditionals ( context ? )
> ./build/property-set.jam:179: [
> $(self.raw) : [
> $(context).raw ] ] ] ;
Yea. The property-set is a class for representing, well, property-set, which
has some big advantages over raw list of properties. It was introduced after
property.jam was written, so forwards a number of calls to property.jam.
> So, if the property.evaluate-conditionals *is* called from
> targets.basic-target.compute-usage-requirements, the next question is,
> obviously, where is this called from.....
Excellent question! Apparently, when property-set class was introduces, all
callers were changed to use it, and property-set.evaluate-conditionals was
changed to use property.evaluate-conditionals-in-context. So,
property.evaluate-conditionals became unused.
I've removed property.evaluate-conditionals and now rerunning tests. Sorry for
> The second obvious question (to me, at any rate) is the strange nature
> of property.evaluate-conditionals.
> rule evaluate-conditionals ( properties * )
> return [ evaluate-conditionals-in-context $(properties) :
> $(properties) ] ;
> Why does this function pass properties *as the context* to
> property.evaluate-conditionals-in-context? It appears, from my reading of
> this function, that all properties in the list will be returned.
> Oh, wait. They won't be returned exactly as they went in, but with the
> conditional part removed. Is that why this is called this way? If so,
> then property.evaluate-conditionals does not really evaluate conditional
> properties to see if they should be included. If that is true then the
> *real* evaluation of conditional properties is done through another path.
Nope, the way it used to work was that if you pass
but if you pass
you get only
As I've said, this function is not longer use, because we have a bit fancier
algorithm for handling with conditionals. It's even documented ;-) Though not
in docs, the algorithm can be found in
and its implementation in in targets.common-properties.
Hope that helps, and I'll try to write some more high-level architecture docs.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk