Rene Rivera wrote:
Peter Dimov wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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