$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