[boost] Re: Customer Friendlier Boost Installation

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. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org