Re: [Boost-build] Newbie questions

Subject: Re: [Boost-build] Newbie questions
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-07-13 08:17:37

On Monday 13 July 2009 Boris Schaeling wrote:

> I'm trying to get familiar with Boost.Build. I read the entire  
> documentation and played around with Jamfiles in some small projects but  
> still have a few questions:
> 
> 1) Do I understand correctly that the project rule doesn't care about the  
> order arguments are passed? For example the sample at  
> http://www.boost.org/doc/tools/build/doc/html/bbv2/advanced/projects.html  
> can also be written as:
> 
> project tennis : : : : : : : : : : : : : requirements <threading>multi :  
> default-build release ;
> 
> The requirements and the default-build do not need to be passed as a  
> second or a third argument. They can be passed anywhere. It's just  
> important that the words 'requirement', 'default-build' or the others  
> recognized by project are used to tell the rule what is actually meant?  
> That said project is a rule with named arguments?

Yes, this is true.

> 2) "default-build release" is the same as "requirements <variant>release"  
> except that it can be overwritten?

Approximately so. default-build takes effect if no other value is explicitly
requested -- typically on command line.
 
> 3) Is the list of builtin feature at  
> http://www.boost.org/doc/tools/build/doc/html/bbv2/advanced/builtins/features.html  
> complete? I wonder as for example on  
> http://www.boost.org/doc/tools/build/doc/html/bbv2/reference/definitions.html  
> a sample uses a property <os> which isn't in the list. Or is <target-os>  
> what has been <os> maybe in an earlier version of Boost.Build?

Yes, <os> is old feature. Use <target-os> or <host-os> these days.

> 4) Does "non-free feature" imply that values are mutually exclusive? Or is  
> there any non-free feature which could be set to two different values in  
> the requirements of the exe rule (without bjam complaining)?

At present, a non-free feature may have only a single value. E.g. every time
a metatarget (aka main target), exactly one value is set for such feature.
You can't have toolset=gcc and toolset=msvc in the same property set.

> 5) If Boost.Build isn't installed separately but as part of the Boost C++  
> libraries, and if my project's boost-build.jam refers to the subdirectory  
> tools/build/v2 of the root directory of the Boost C++ libraries can I link  
> more easily to a Boost C++ library without putting a hardcoded path into  
> my Jamfiles? It would be great if I could use a variable like BOOST_ROOT  
> knowing that it is automatically defined and set by Boost.Build. I guess  
> it would require Boost.Build to check if it's installed as part of the  
> Boost C++ libraries so it can find out itself somehow?

At present, Boost.Build is not checking if it's inside Boost tree, or not.

HTH,
Volodya