"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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 http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_V... ? -- Dave Abrahams Boost Consulting www.boost-consulting.com