Boost logo

Boost-Build :

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
> 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
> complete? I wonder as for example on
> 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.


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at