From: David Abrahams (dave_at_[hidden])
Date: 2005-05-26 17:24:04
"Peter Dimov" <pdimov_at_[hidden]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>> 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.
Oh, weird. I just never thought of it from the angle that you're
going to wait for an error and then figure out what to build. But I
suppose you'll have the same problem if you built the wrong thing to
begin with; then you'll still have to poke around to figure out how
the system wants you to describe the library.
> If I am expected to be able to do that, so can Boost.Build, right?
Well, let me put it this way: in theory it can, but the library name
can't be treated like an ordinary target. We could see if we can find
a target with that name, and if not, try to decode it as a tagged
library name and construct a new virtual command-line.
> It can even get them right the first time. I average about 2.5
Good idea. Could you put this on
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk