Multiple Buildspaces
Rogue Wave buildspaces are very flexible. You can build different groups of components in a variety of build configurations all within the same buildspace. The product-specific directories, such as
tools and
trace, and configuration-specific directories, such as
12s (both shown in
“Results of Running a Buildspec”) keep everything organized for you.
Using an Imported Buildspec
It is possible to select a buildspec from one buildspace and place that buildspec into a different buildspace. This feature allows you to use an already existing buildspec stored on a network to build a set of components in your local buildspace.
For example, your colleague has a buildspec that you require. Instead of going through the entire RCB question sequence to create a buildspec similar to the one that you require, you can use the original buildspec and store it to your local buildspace. This will save your colleague’s buildspec into your local buildspace\records\specs directory.
NOTE >> If the imported buildspec has the same name as a buildspec in the target buildspace, the copy saved in the target buildspace will overwrite the original buildspec. You can avoid this by specifying a user tag in the build tag naming convention option for the imported buildspec. The user tag becomes part of the buildspec name, making it different from the name in the target buildspace.
Using the Export Buildspace Feature
The export buildspace feature allows you to use source files from one buildspace but export the build results to another location. This location can be any directory that is not (and is not contained in) an existing local buildspace, or an incompatibly configured export buildspace. You might use this feature to:
• Use resources from one buildspace to create libraries in another buildspace.
• Export build results to a common location where colleagues have access to it. (Keep in mind that they must have a license to use the components.)
• Export build results to a remote location with more disk space so you do not fill up your local drive.
• Work around the limitation on UNIX that RCB does not support symbolic links.
In an exported buildspace, there is a special requirement to run the examples for libraries that have 3rd-party dependencies. For the examples to work, they need to know the location of the 3rd-party libraries. If you use one of the 3rd-party libraries that ship with SourcePro, those libraries are located back in the source buildspace, not in the exported buildspace where the example executables are located. On the exported-buildspace machine, use the system variable LD_LIBRARY_PATH (UNIX) or PATH (Windows) to point to the 3rd-party library location in the source buildspace.
The 3rd-party libraries can be found in the 3rdparty directory of the source buildspace. For example, for the OpenSSL library on a Windows 32-bit machine running MSVC 12.0, the library path would be <installdir>\3rdparty\openssl-<ver>\windows\ia32-msvc12.0\bin.
The same issue applies to developing an application in an exported buildspace using a SourcePro module with 3rd-party dependencies: the include path specification must point back to the source buildspace for the 3rd-party library. For the above example, the path would be <installdir>\3rdparty\openssl-<ver>\windows\ia32-msvc12.0\include.