|
Boost : |
From: Tony Juricic (tonygeek_at_[hidden])
Date: 2004-10-27 07:17:53
Just checking on my understanding of the motivation for current library
names, prompted by some work on updating Visual Studio IDE projects.
I assume that Boost version, build (i.e. debug or release) and CRT specific
names like:
libboost_serialization-vc71-mt-1_32.lib,
libboost_serialization-vc71-mt-gd-1_32.lib and similar
are intended for binary distribution of libraries, where end user is not
even expected to use bjam, but simply link with the library that she needs.
OTOH, the executables link with version, build and CRT-linkage independent
library names like: libboost_serialization.lib.
I assume that this is done simply for build convenience, since library is
nothing else but a packaged set of object modules, whatever name you give to
it.
In fact, when I build boost with VC++ 7.1, using command:
bjam -sTOOLS=vc-7_1<RETURN> (VC++ 7.1 environment variables are assumed set
at this point)
in my
"...bin\boost\libs\test\build\libboost_test_exec_monitor.lib\vc-7_1\debug\th
reading-multi" directory I see both
libboost_test_exec_monitor-vc71-mt-gd-1_32.lib
and
libboost_test_exec_monitor.lib
libraries, and, as I would expect, they are exactly identical.
The *only* case where both libraries are *not* built is for
"runtime-link-static\threading-multi" build, where I see only
version-specific library, such as
libboost_test_exec_monitor-vc71-mt-sgd-1_32.lib, for example.
Am I missing some deep rationale behind the build logic and names given to
the libraries, or?
Tony
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk