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,
>> 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:
Would be, in BBv1, equivalent to:
bjam "-sBUILD=release <runtime-link>dynamic/<threading>multi"
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk