The figure below shows the elements that make up the library names generated by Software Parts Manager. The following sections then explain the possible values for each element.
The prefix is "lib" for Unix platforms, absent otherwise.
Product Mnemonic
The following table shows the standard mnemonics for all Rogue Wave products.
DLLs created for a shared library build on Windows platforms may include a one- or two-digit number representing the major and minor release numbers of the part used in the build. For example, the version number "70" for Tools.h++ would represent major release 7.0 (before any minor releases). The actual version used in the build could include a maintenance release number, as in 7.0.8. A possible DLL name, then, for a Tools.h++ build would be tls703d.dll
, where "70" represents the version and "3d" represents the build type.
Build Type Code
The build type code is generated from a four-bit field where each bit indicates the setting for some build option. The meanings of the bit positions are shown in the following table:
The following table shows the full set of option settings for each build type code. For this release of Software Parts Manager, debugging always means that both symbolic debugging and RWDEBUG have been implemented in the build. Also, beginning with the Nov 1997 release, the Standard C++ Library uses codes 8 through 15 for compatibility with products built on top of it.
The following table shows the two possible values for the linkage type code:
CBM includes a provision for adding a custom suffix to generated library names. This suffix may prove useful to distinguish the library names of different build configurations you define.
This suffix is also added to DLL names, which provides a way of avoiding a potential collision of these names: DLLs built with the same build type and linkage option under the Msvc and Borland compilers will have the same name, posing an identification problem. To avoid this, you can create a custom compiler properties file that specifies, for example, a "b" suffix for DLLs compiled under Borland, thus creating a distinct name.
The platform extension depends on the extension conventions for the platform targeted in the build. For most UNIX platforms, the value varies depending on the linkage type.