Re: [boost] bjam variants, subvariants and default build

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-07-16 00:41:33

[2002-07-15] Gennadiy Rozental wrote:

>Hi,
>
> I would like to clarify some issues with Boost.Build system to make sure
that I 
>understand everything clear.

Cool, I'll try to answer as many as I know... But from now on could you
direct the Boost.Build trafic to the jamboost_at_[hidden] list, or the
news equivalent gmane.comp.lib.boost.build. It will help me get to your
email faster.

I'm redirecting this, and hopefully other responses there :-)

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

Yes.

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

bjam -sBUILD="<threading>multi"

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

Basically... but the details are nightmarish :-)

> Couple questions:
>1. What is the practical difference between
>
>lib my_lib : source.cpp
> :
> : release <threading>multi
> ;

It works, and is correct.

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

Doesn't work, and is incorrect. AFAIK

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

<runtime-link>static ... links against static C/C++ runtime libraries, for
GCC this turns into the "-static" option.

<runtime-link>dynamic ... links against dynamic (DLL or SO) C/C++ runtime.

Not implied by lib, nor dll. Only <shared-linkable>true is implied by dll.

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

The global default is in the DEFAULT_BUILD variable. But changing that
really does change it globally. Everything will then build with that
default. So unless you are doing this in your own PRIVATE BUILD TREE don't
do it. And especially don't do it in a toolset, I don't even know what the
consequences would be.

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

Ahh, a really tricky question... I usually add a compiler specific
requirement to the target I'm interested in like so for GCC:

exe fubar : fubar.cpp : <gcc><*><cflags>-E : ;

The drawback is that the preprocessed output goes to a *.o/*.obj file.

>P.S. Is there final patch for ambiguity issue?

Which issue was this again? Did I miss that email?

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

No it's not supposed to do that... thankfully I already fixed that (AFAIK)
on Sunday night :-) So if you still see that behaviour with the latest CVS
code yell.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]