Builds of Rogue Wave libraries through Software Parts Manager are based on sixteen standard build types. The build options that determine these twelve types are described in the next section, followed by a summary table.
The Rogue Wave build types are based on four build options. Each of these is described below.
Each option description concludes with some remarks on the implications for the compiler command line invocation needed to build applications that depend on Rogue Wave libraries. Note, however, that these remarks do not necessarily cover all command line requirements.
The four variables are:
Does the library depend on the Standard C++ Library?
Tools.h++ can be built as either Standard C++ Library-dependent or not. If Tools.h++ is built as dependent, any libraries built on Tools.h++ must also be built as Standard C++ Library-dependent.
Rogue Wave offers an implementation of the Standard C++ Library, but you are free to use other implementations.
Command line implications: For MSVC, there are three mutually exclusive macros: the Standard C++ Library is not in use (RW_NO_STL); the Rogue Wave implementation of the Standard C++ Library is being used (RW_RWV12_STDLIB); or the MSVC version of the Standard C++ Library is being used (RW_MSVC_STDLIB).
Does the library support multithreading?
Support for multithreading means that the library is "multithread safe."
However, you should be aware that there are two levels of multithread safety:
MT-safe: level 1. At this level, a safe routine, class, or library may be accessed or executed from within a multithreaded application. Safe objects are re-entrant and protect their internal global or static data from corruption by multiple threads. However, a safe object does not necessarily support concurrency. That is, a safe routine, class, or library may require explicit global or local locking and unlocking of objects to achieve some level of concurrency.
MT-safe: level 2. This safety level provides for a reasonable degree of concurrency. That is, explicit locking and unlocking is not generally required, except possibly in situations where several individual operations must be combined and treated as a single atomic operation (testing for and reading the contents of a queue, for example).
Rogue Wave's support for multithreading is generally at level 1, but check a library's User's Guide for details of that library's multithread support.
Command line implications: The use or non-use of multithreading generally affects at least one compiler flag, and may require one or more macros to be declared, particularly if an application depends on Threads.h++.
Does the library support debugging?
If the build type specifies Debug, two independent debugging facilities are activated:
Tools.h++ RWDEBUG facility.
RWDEBUG activates a set of PRECONDITION and POSTCONDITION clauses at the beginning and end of critical functions. These pre- and post-conditions are implemented with asserts. A failure causes the program to halt after first printing out the offending condition, along with the file and line number where it occurred.
Compiler source code debugging
A debug build type implies that the compiler's debug flag has been set.
The alternative to a Debug build is called Release, for which neither debugging facility is activated.
Command line implications: For Debug builds of Tools.h++ and libraries or applications that depend on Tools.h++, the RWDEBUG macro is required, and possibly other macros. In all cases, the compiler's debugging flag must be set. To build a library through Software Parts Manager that activates just one of the debugging facilities, you must customize a Release build type to add either RWDEBUG or the compiler debugging flag.
Is the library static or shared?
Command line implications: Static linking is relatively straightforward, requiring only that the required libraries be linked in. (For DBTools.h++, this includes an access library object module and library file.) Shared linking (also called DLL or dynamic linking) is more complex. On Unix platforms, the environment must be set to point to the required shared libraries. On Windows, you must set the macro RWDLL, which activates product-specific DLL macros for any Rogue Wave libraries you are using. Also, Windows-specific and sometimes compiler-specific macros are required.
Table 1 shows the build type designators used in library and directory names, gives the full name used by Software Parts Manager, and shows the state for each of the four variables discussed above.
Build type | Full name | Standard Library | Threading | Debugging | Static or Shared |
0s |
SingleReleaseStatic |
Not used |
Single thread |
No debugging |
Static |
0d |
SingleReleaseShared |
Not used |
Single thread |
No debugging |
Shared |
3s |
SingleDebugStatic |
Not used |
Single thread |
Debugging |
Static |
3d |
SingleDebugShared |
Not used |
Single thread |
Debugging |
Shared |
4s |
MultiReleaseStatic |
Not used |
Multithread |
No debugging |
Static |
4d |
MultiReleaseShared |
Not used |
Multithread |
No debugging |
Shared |
7s |
MultiDebugStatic |
Not used |
Multithread |
Debugging |
Static |
7d |
MultiDebugShared |
Not used |
Multithread |
Debugging |
Shared |
8s |
SingleReleaseStdLibStatic |
Used |
Single thread |
No debugging |
Static |
8d |
SingleReleaseStdLibShared |
Used |
Single thread |
No debugging |
Shared |
11s |
SingleDebugStdLibStatic |
Used |
Single thread |
Debugging |
Static |
11d |
SingleDebugStdLibShared |
Used |
Single thread |
Debugging |
Shared |
12s |
MultiReleaseStdLibStatic |
Used |
Multithread |
No debugging |
Static |
12d |
MultiReleaseStdLibShared |
Used |
Multithread |
No debugging |
Shared |
15s |
MultiDebugStdLibStatic |
Used |
Multithread |
Debugging |
Static |
15d |
MultiDebugStdLibShared |
Used |
Multithread |
Debugging |
Shared |
©Copyright 1999, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.