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