Boost libraries naming convention

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

Tony Juricic wrote:
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.
Correct... Other than the initial use of bjam to build+install.
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.
Correct... The unversioned names are optimally hard-links to the versioned names. Since link support is less than stellar on Windows, the build does a copy instead on the platform. But on *nix it does a real hard-link.
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.
I don't expect it. And it doesn't create those for me unless I "stage" or "install".
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?
I think you are confusing the non-install builds with the install ones. If you use the same tree to do testing, examples, or other build you will get bare names (bare = unversion, no variant, no toolset). If you want to see what the build+install does I suggest you locate it apart from the Boost tree with the "--builddir" option, and possibly "--prefix", and "--stagedir". Additionally a new option this time around is "--layout". Which system integrators can use as "--layout=system" to get mostly untagged names. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (2)
-
Rene Rivera
-
Tony Juricic