Boost logo

Boost :

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,
>> 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.

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
> tries.


Good idea. Could you put this on

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at