Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-07-15 23:52:41


Hi,

  I would like to clarify some issues with Boost.Build system to make sure that I understand everything clear. As far as I understand bjam defines notion of "simple feature" that may have several values; one of them is default. Also jam defined notion of "variant" as predefined list of "feature-value" (properties).
Default variant is always debug. So that if we do nothing

lib my_lib : source.cpp
           ;

all defined featured have values specified by default variant or default values.
  Now lib (dll,exe,...) rule have "requirements" section where we can define non-default values for the features that are intrinsic for the target.

lib my_lib : source.cpp
           : <threading>multi
           ;

This way I enforce defined value for the feature and do not allow setting different value for this feature, for example, from command line.
  We could also change default build configuration using third section of lib (dll,exe,...) rule.
lib my_lib : source.cpp
           :
           : <threading>multi
           ;

This way I enforce defined value for the feature to be set by default but allow setting different value for this feature, for example, from command line (BTW how to do this?).
   Any feature that does not belong to the list of features defined by variant cause branching to subvariant (even if it has default value). Multiple values for the feature defined in third section automatically make jam build several subvariants.
  Couple questions:
1. What is the practical difference between

lib my_lib : source.cpp
           :
           : release <threading>multi
           ;

and

lib my_lib : source.cpp
           :
           : <release><threading>multi
           ;

2. What is <runtime-link>? Does it implied by the rule (lib,dll)? Could I set it explicitly?

3. Is there way to change the default (and non-default) variant in toolset definition?
Let say I introduced 10 new features in toolset definition. Building debug configuration will introduce way to long subvariant grist: variant/feature1-value1/feature2-value2/..../feature10-value10
I would like to have an ability to extent build variants my features. I know that I could extent variant. But how to change the default?

4. unrelated question, but still, since you mention it once: how to get the preprocessor result with bjam?

Thank you,

Gennadiy.

P.S. Is there final patch for ambiguity issue? BTW I remarked another "strange" behavior of bjam. Let say I have <threading>single/multi in default-BUILD section of my library lib rule. bjam builds 2 subvariant of my library in .../runtime-link-dynamic/threading-single and .../runtime-link-dynamic/threading-multi subdirectories. Let also say I have exe target that need to link with my library above but does not specify <threading> feature nor in requirement nor in default-build section. bjam will build THIRD version of my library in .../runtime-link-dynamic with default <threading>. Is it supposed to be that way?

_____________________________________________________________
A free email account your friends will never forget!
Get YOURNAME_at_[hidden] at http://www.emailaccount.com/

_____________________________________________________________
Promote your group and strengthen ties to your members with email_at_[hidden] by Everyone.net http://www.everyone.net/?btn=tag


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk