From: Jim Gallagher (jim_at_[hidden])
Date: 2008-08-20 14:32:32
> If someone can specify the exact algorithm for deducing which runtime
> library is used, perhaps something could be done about this but I am not
> really sure I follow you here. How does choosing the compiler/linker
> cause you to link to a different runtime library? That seems like an
> orthogonal issue and you should be able to configure your build to use a
> new compiler and an older run-time library and vice versa.
> On the other hand, perhaps there could be some use in teaching MSVC
> to differentiate between SP1 and noSP version of msvc-8.0 but I am not
> really sure how that could be done.
> Feel free to look through the tools/msvc.jam module which implements
> all the msvc toolset autodetection logic and suggest patches.
> Best regards,
> Jurko GospodnetiÄ
I believe that each version of MSVC ships with a set of import libs
for the runtime
and are tied to a specific version of the runtime. It may be possible
a given version of the toolchain to link against a set of import libs
that came with
a different version, but that does not seem like an attractive proposition.
In a different build environment that I support, I simply use the version
identifier of cl.exe (as output in the info message when invoked without any
options) to identify the runtime lib version. I do not have enough
data to say that this
is a full-proof method, but it seems to work.
On a different note, are the docs for the Perforce version of Jam
still applicable to
the Boost version? I'm having trouble getting up the Jam learning
curve using the
Boost.Build V2 User Manual, so I'm looking for additional docs to help me out.
I have been looking though the different config files, like msvc.jam,
but I just don't
understand enough yet to make intelligent changes.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk