Select Naming Convention
These questions determine the string that is used in the built component names to indicate the build type. For example, in the library name tls12s.lib, the build tag part is 12s.
When you select a convention, the Build tag and Description fields are filled in automatically based on answers to previous questions. The User-defined tag field allows you to add your own identifier to the component name.
NOTE >> The build tag also determines the buildspec name; that is, a build tag of 12s creates a buildspec of the name 12s.bsf. If your buildspace already contains a buildspec for the configuration you are defining, the new buildspec will overwrite the existing one unless you specify a different naming convention or supply a user-defined tag.
The easiest solution is to define a user-defined tag, which becomes part of the buildspec name, making it different from the existing one. For example, the user-defined tag “_solaris” would change the buildspec name 12s.bsf to 12s_solaris.bsf, thus preserving the existing buildspec.
Naming Conventions
The
Select a naming convention drop-down menu offers three choices.
Table 3 summarizes the types of build tags each choice generates.
Table 3 – RCB component naming conventions
Convention | Description |
SPM | Tags used by Software Parts Manager (SPM), such as the 12s tag shown above. This choice is provided for backwards compatibility so you can produce components through RCB with the same naming conventions as those produced through SPM. |
RCB | A system of one-letter codes to indicate certain build options. The advantage is concise component names, but a drawback is the need to remember the codes. The codes are explained in Table 4. |
Verbose RCB | A long but clear sequence of strings, delimited by underscores, for indicating a component’s build characteristics. |
Table 4 lists the codes used in the RCB convention.
Table 4 – Codes used in the abbreviated RCB build tag convention
Code | Meaning |
s
no code | Using STLPort on Solaris platforms
Using the compiler’s native standard library |
m
no code | Multithreaded build
Single-threaded build |
s
no code | Static binding
Dynamic binding (also called shared or DLL) |
d
no code | Debugging build
Release build |
Note that there is some ambiguity due to the use of ‘s’ to denote either static builds or the use of STLPort on Solaris. However, in practice the chance for confusion is minimal. Solaris is the only platform where the ambiguity might occur, and even there the library extension should disambiguate whether a lone ‘s’ in the library name stands for a static build (.a extension) or the use of STLPort (.so extension).
Build Tags
Table 5 summarizes the build tags created by the different conventions.
Table 5 – Summary of build tags
Build Options | Build Tags |
Dynamic | Threads | Debug | RCB | Verbose RCB | SPM |
N | N | N | s | _NativeStdLib
_NoThrLib_Static_Release | 8s |
Y | N | N | no tag | _NativeStdLib
_NoThrLib_Dynamic_Release | 8d |
N | N | Y | sd | _NativeStdLib
_NoThrLib_Static_Debug | 11s |
Y | N | Y | d | _NativeStdLib
_NoThrLib_Dynamic_Debug | 11d |
N | Y | N | ms | _NativeStdLib
_Win32ThrLib_Static_Release | 12s |
Y | Y | N | m | _NativeStdLib
_Win32ThrLib_Dynamic_Release | 12d |
N | Y | Y | msd | _NativeStdLib
_Win32ThrLib_Static_Debug | 15s |
Y | Y | Y | md | _NativeStdLib
_Win32ThrLib_Dynamic_Debug | 15d |
/images/Select-Naming-Convention.png)