$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-05 12:18:03
Rene Rivera wrote:
> Peter Dimov wrote:
> 
>> David Abrahams wrote:
>>
>>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>> 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.
> 
> 
Actually we don't have to be very precise. I wouldn't complain if I had 
just a piece of documentation how to build ALL 
[lib]boost_thread-vc71-*-1_33 flavours at once.
Can anyone give me such examples for both bbv1 and bbv2?
Andrey