Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-05-26 16:40:00

Peter Dimov wrote:
> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>> That aside, FWIW I've found bjam relatively painless to use (once
>>> it's present). I didn't even need to specify an -sTOOLS option or run
>>> vcvars32.bat IIRC. For the scenario where one already has the
>>> headers up and running but doesn't want to "bjam install" the whole
>>> package, the main obstacle is figuring out which -sBUILD combination
>>> generates "library-sgd-mt-whatever" when autolinking kicks in.
>>> Or can bjam figure these out automatically from the target name of
>>> "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
>> No, it can't. The presumption is that -SBUILD="..." specifications
>> are higher level than sgd-mt-whatever abbreviated tag strings. Of
>> course, -sBUILD is still pretty awful in v1. In v2 you just write,
>> e.g.
>> bjam threading=multi link=static <library-name>
>> if you want to build a library with specific options.
> This is better. But my point is that the linker doesn't tell me anything
> about threading=multi or link=static. It tells me the exact name of the
> .lib file, and I'm supposed to reverse engineer the sgd-mt-whatever
> string and come up with the higher-level options. If I am expected to be
> able to do that, so can Boost.Build, right? It can even get them right
> the first time. I average about 2.5 tries.

I think it would be possible to add the pseudo-targets so that doing:

        bjam libboost_thread-vc71-mt-1_33.lib

Would be, in BBv1, equivalent to:

        bjam "-sBUILD=release <runtime-link>dynamic/<threading>multi"
--with-thread stage

Something similar could be done in BBv2.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - Grafik/

Boost list run by bdawes at, gregod at, cpdaniel at, john at