Build types are shown as <buildtype> in this manual. They are used in the workspaces directory structure (described in Section 2.3) and in library names (described in Section 2.4).
Build types use the following encoding scheme:
<build#><binding><suffix>
Table 8 explains this scheme.
Code | Meaning |
<build#> |
The build number. Possible build type numbers for this product and the build that they specify are: 0 = no stdlib, single thread, no debugging features 3 = no stdlib, single thread, symbolic debugging and assertions 4 = no stdlib, multithread, no debugging features 7 = no stdlib, multithread, symbolic debugging and assertions 8 = stdlib, single thread, no debugging features 11 = stdlib, single thread, symbolic debugging and assertions 12 = stdlib, multithread, no debugging features 15 = stdlib, multithread, symbolic debugging and assertions |
<binding> |
The library binding: s = static d = dynamic (DLL) /shared |
<suffix> |
A user-defined library name suffix used to distinguish custom build configurations. By default, <suffix> is blank. The SPM online help explains how to add or edit customized build configurations. |
For example, if you have a static, multithreaded library with symbolic debugging and assertions, the build type is:
7s
The same library could have a user-defined library name suffix such as _test as in this example:
7s_test
©Copyright 1999, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.