Boost logo

Boost-Build :

From: Mark Elston (m.elston_at_[hidden])
Date: 2004-06-24 13:52:04


Again, thanks.

Now that I look at that section in the docs I do see it. I must
have zoned out a little when reading it the first couple of times.
Sorry about that.

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? 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).

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 it so I did the following from the v2
directory:

find . -name '*.jam' -exec grep evaluate-conditionals {} /dev/null \;

to find where it might be called from but I wasn't sure how to evaluate
the results since some of the resulting list was, in itself, confusing.

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 ] ] ] ;

This starts a rule definition:

./build/property.jam:89:rule evaluate-conditionals-in-context ( properties
* : context * )

These two belong to the evaluate-conditionals rule itself:
./build/property.jam:121:rule evaluate-conditionals ( properties * )
./build/property.jam:123: return [ evaluate-conditionals-in-context
$(properties) :
$(properties) ] ;

This one is part of a test:

./build/property.jam:554: : evaluate-conditionals <toolset>gcc
<variant>release
<rtti>off

This is from targets.common-properties2. It does not call
property.evaluate-conditionals:

./build/targets.jam:804: local e = [
property.evaluate-conditionals-in-context
$(conditionals)

A possibility. This is from
targets.basic-target.compute-usage-requirements.
Note, however, that it calls
$(self.usage-requirements).evaluate-conditionals,
not property.evaluate-conditionals:

./build/targets.jam:1044: xusage-requirements = [

$(self.usage-requirements).evaluate-conditionals

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.....

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.

Have I missed something?

Mark

> -----Original Message-----
> From: Vladimir Prus [mailto:ghost_at_[hidden]]On Behalf Of Vladimir
> Prus
> Sent: Wednesday, June 23, 2004 10:16 PM
> To: jamboost_at_[hidden]
> Subject: Re: [jamboost] Project setup - again
>
>
> Mark Elston wrote:
> > One last question (that I can think of).
> >
> > Can I stack those conditions in a conditional property? For
> > example,
> >
> > <os>LINUX:<variant>debug:<cxxflags>-whatever
>
> Yes, but not with this syntax, you'd need
>
> <os>LINUX,<variant>debug:<cxxflags>-whatever
>
> (i.e. comma instead of semicolon). BTW, I think this part is
> somewhere in the
> docs:
>
>
> http://boost.org/boost-build2/boost_build_v2.html#conditional_properties
>
> > Ok. One more. Is there somewhere in the code I can look at
> > to find out more about this behavior (either C or Jam code)?
>
> Sure. The entry point for conditionals handling is
> evaluate-conditionals in
> build/propery.jam
>
> HTH,
> Volodya
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

 


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