This section compares and contrasts SPM with RCB.
SPM installed components into a parts tree and built them in a workspace. SPM builds were said to be of a certain build type.
With RCB, components are installed into a buildspace, where the RCB application also builds them. The term buildspace replaces the SPM term workspace, which tends to be confused with the Microsoft use of the term. Because the buildspace combines the functions formerly served by both the workspace and parts tree, the term parts tree goes away entirely.
The RCB term build configuration is equivalent to the SPM term build type. The build configuration is a part of the build specification (often abbreviated to buildspec), but only a part.
Section 1.2 provides additional information about RCB terminology.
SPM both installed and built components. At most, SPM could build a single product and its example set. A build was defined by a particular combination of operating system, compiler, and build type, and the results were stored in a separate workspace at the bottom of a deep directory structure.
With RCB, installation is through the almost universally familiar InstallShield/InstallAnywhere installation process, as explained in Section 2.2. Builds are carried out through a wizard-like interface, which assists in the creation of buildspecs. A buildspec is passed to the build manager, which conducts the actual build.
A buildspec could be defined to build all Rogue Wave components in some build configuration. Furthermore, buildspecs are added to a build queue, allowing you to run any number of specifications through the build manager with a single click of a button. Potentially, you could build all of the SourcePro C++ components in all of their valid build configurations in a single operation.
Section 1.2 and Section 2.1 provide additional information about RCB processes.
As mentioned above, the SPM directory structure was both more complex, distributing source and compiled components between two directory trees (not to mention the separate SPM directory structure), and deeper than the comparable RCB structure. The simplest way to illustrate this difference is by showing the directory structures that would result from building a couple of Rogue Wave products under two different build configurations using SPM and RCB.
Let us suppose, therefore, that we are building:
In SPM, Tools.h++ and Threads.h++; in RCB, the nearly identical case of the Essential Tools Module and the trace package from the Threads Module
The 12s and 15d build configurations
On Windows
Using the MSVC 6 compiler
Here is what the two directory structures would look like:
The notations on directory contents in the two directory structures are worded the same to help you map the differing locations of important files between the two systems. (In online format, color coding lends further assistance.)
Notice that the requirements for linking in libraries and including header files is equivalent between the two systems. That is, the path to built components is
spm_workspace/lib and rcb_buildspace/lib
while the include path for header files is simply
spm_workspace or rcb_buildspace.
Of course, there is the difference that for a root directory of c:\rwav the variable spm_workspace expands out to c:\rwav\workspace\WINNT4\MSVC60\15d, while rcb_buildspace remains simply c:\rwav.
This deliberate similarity will be significant in the next section.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Contact Rogue Wave about documentation or support issues.