There are two main directory trees associated with Rogue Wave libraries:
Product installation locations (parts directory tree)
Product build locations (workspaces directory tree)
Software Parts Manger requires that you specify a Rogue Wave root directory. The product installation and build directory trees are located below this system location, which this guide indicates as <rw_root>.
Figure 1 shows a typical product installation directory tree, or product tree, using Tools.h++ as the example.
Products are installed in the parts directory below <rw_root>. Each product has its own product tree within parts, beginning at a directory named with the official Rogue Wave product mnemonic, a three-digit version number, and a one-letter operating system designator. In the above figure, this consists of tls for Tools.h++, nnn for the version number, and w for Windows (the other possibility being u for Unix).
Within the product tree, there is a source directory that contains, in the simplest case, an etc directory holding files used by Software Parts Manager in the generation of makefiles, and a src directory containing the library source files and, in the src/rw subdirectory, the library header files. For some products, there may be subdirectories below source for divisions of the product, but at the end of any branch there is always an etc and src directory pair.
Also within the product tree is an examples directory containing the source, header, and makefile support files for examples supplied with the product. The structure is similar to that of the source directory.
The docs directory contains at least the product readme file, and may contain other informational text files. It is always a good idea to have a look at any files placed in this directory.
Product builds take place in a workspace, and it is here you will find all the support files used by Software Parts Manager in the build and the resulting library and object files. Figure 2 shows a workspace containing the results of two library builds, for Tools.h++ and Threads.h++.
Within the workspaces directory under <rw_root>, Software Parts Manager creates a workspace for each combination of operating system, compiler, and build type that you use to build one or more libraries. The example shows that there would be two separate workspaces for MSVC 5.0 builds on Windows 95 using the build types 3s and 6d. (See Section 4.1 for an explanation of build types.)
Maintaining a separate workspace for each unique build configuration avoids confusion among library builds. It also provides a central location for all the resources you need to build applications that depend on some combination of libraries and a particular build configuration.
Each workspace contains four main subdirectories: lib, rw, buildloc, and examples.
The lib directory contains all the compiled libraries. See the Software Parts Manager online help for an explanation of library naming conventions. This directory also contains the build record for each build, saved under <product name>.rec, such as tools.rec for Tools.h++.
The top level of the rw directory contains the header files for Tools.h++ -- assuming you have built this library, which is a pretty sure bet -- and two important support files:
config.dat -- A data file containing important information about the capabilities of your compiler. This file is generated by a script that exercises your compiler the first time the compiler is used for a particular build configuration.
compiler.h -- A header file containing compiler-specific settings and required for building Tools.h++.
The rw directory also contains a subdirectory for each product whose library you have built in the workspace, containing the product's header files. The one exception is Tools.h++, whose header files are in the main rw directory. For Tools.h++ there is a stdex subdirectory, which contains Standard C++ Library-related header files.
The buildloc directory is where the builds themselves take place. There is a subdirectory for each built product, named with the official Rogue Wave product mnemonic, a three-digit version number, and a one-letter operating system designator. For Tools.h++ in the above example, this consists of the Tools.h++ mnemonic tls, nnn for the version number, and w for Windows (the other possibility being u for Unix). Look in buildloc for the object files generated in the build and the makefile used by Software Parts Manager.
Normally, the source code remains in the product tree. An option in the Advanced dialog off of the Software Parts Manager Build dialog allows you to copy the source code to the workspace, in which case it goes into the product directory under buildloc.
The examples directory contains a subdirectory for each product whose examples you have built, with that subdirectory containing the source code, makefile, and resulting executables. For some products, the product subdirectory within examples may contain additional subdirectories for different example sets.
©Copyright 1999, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.