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 shown in Section 2.7, and configuration-specific directories, such as 12s shown in Section 2.7, keep everything organized for you.
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.
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.
If the Platform Information Exchange is installed and RCB was previously activated, a user consent setting is set regarding the forwarding of buildspec data to Rogue Wave. This setting is stored in your RCB user profile.
The Platform Information Exchange has another setting known as a restriction setting. The restriction setting is created when a buildspec is created. Its value is derived from the user consent setting and is stored in the buildspec file.
The restriction setting prevents data from being inadvertently sent if buildspec files are shared between RCB users with different user consent settings. Unless both parties have selected settings that allow the sharing of information with Rogue Wave, RCB will not send any data.
For example:
User A selects Yes, automatically gather and forward the data upon build creation and creates a buildspec. User B selects Maybe, ask me to decide that for each build. User B begins to modify the buildspec created by User A. When User B finishes modifying that buildspec, RCB requests permission to send that buildspec information to Rogue Wave.
User A selects Yes, automatically gather and forward the data upon build creation and creates a buildspec. User B selects No, never gather or forward information about my builds. User B begins to modify the buildspec created by User A. When User B finishes modifying that buildspec, RCB will not send information, nor request permission to send information. This will not change until User B's consent setting is changed to an option that allows the sharing of buildspec data.
User A selects No, never gather or forward information about my builds and creates a buildspec. User B selects Yes, automatically gather and forward the data upon build creation. User B begins to modify the buildspec created by User A. When User B finishes modifying the buildspec, RCB will not send information, nor request permission to send information. This setting will never change because User B cannot override User A's restriction setting.
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 C++, 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 9, the library path would be <installdir>\3rdparty\openssl-<ver>\windows\ia32-msvc9.0\bin.
The same issue applies to developing an application in an exported buildspace using a SourcePro C++ 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-msvc9.0\include\openssl.
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.
Provide feedback to Rogue Wave about its documentation.