Re: [boost] Boost libraries naming convention

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-10-27 20:33:16

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