Re: [jamboost] Project setup - again

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 
"v2" directory.

> 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: [
> property.evaluate-conditionals-in-context
> $(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 
confusing you.

> 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

<variant>release <variant>release:<cxxflags>--foo

you get

<variant>release <cxxflags>--fo

but if you pass 

<variant>release <variant>debug:<cxxflags>--foo

you get only

<variant>release

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

http://zigzag.cs.msu.su:7813/properties.txt

and its implementation in in targets.common-properties.

Hope that helps, and I'll try to write some more high-level architecture docs.

- Volodya

- Volodya