Doc error on Getting Started page

On the page (http://www.boost.org/more/getting_started.html), the following text (under the Build/Install section)is inaccurate. There are additional options as supported by Boost.Build and Boost.Jam. Of the additional options perhaps the most imporant is "-sBUILD=<features/variants>" which lets you override what is built by default. The "<features/variants>" value is a list, separated by spaces, of build requests. Features take the form of a tag and a value or values. And variants are single symbolic names for a collection of features. For example the default is to request "debug release <runtime-link>static/dynamic <threading>single/multiple", in which "debug" and "release" are variants, and the rest features with two values each. The main problem is that this is considered (by myself and maybe others) as an example. However, actually issuing this command does not properly build multithreaded code. The jamfiles apparantly interpret "<threading>multi" differently from "<threading>multiple" and we do end up with a "<threading>multiple" set of libraries, but they are not built with threading enabled. To get threading enabled, one must use "<threading>multi" instead. This brings up another issue. Should the jamfiles correctly accept threading attributes which are not properly interpreted? Since I am not a jam expert, and have no idea how difficult this is to fix, I'll leave it alone, and make sure my incantations are properly formed. However, it should be addressed in some form, especially since the official docs even seem a bit confused.

I forgot to add that the "stage" and "install" targets are cool, and go a long way to solving my biggest issue with using boost in other projects. Thanks to all for their work on those (seemingly insignificant) issues. -- Jody Hagins Accordion, n.: A bagpipe with pleats.

Jody Hagins wrote:
On the page (http://www.boost.org/more/getting_started.html), the following text (under the Build/Install section)is inaccurate. [snip]
The main problem is that this is considered (by myself and maybe others) as an example. However, actually issuing this command does not properly build multithreaded code. The jamfiles apparantly interpret "<threading>multi" differently from "<threading>multiple" and we do end up with a "<threading>multiple" set of libraries, but they are not built with threading enabled. To get threading enabled, one must use "<threading>multi" instead.
Oops.. thanks for pointing it out.
This brings up another issue. Should the jamfiles correctly accept threading attributes which are not properly interpreted? Since I am not a jam expert, and have no idea how difficult this is to fix, I'll leave it alone, and make sure my incantations are properly formed. However, it should be addressed in some form, especially since the official docs even seem a bit confused.
Boost.Build should complain about such things. So I guess that's another bug :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (2)
-
Jody Hagins
-
Rene Rivera