Index
CBM User Guide

Compatibility Issues

This topic discusses the compatibility implications for existing applications and IDE settings associated with two possible upgrade scenarios:

There is also a discussion of a change in the build type codes for the Standard C++ Library.

Case 1: Upgrading a pre-November 1997 SPM or CBM build

Beginning with the November, 1997 release of the Software Parts Manager CD, the default workspace location for built libraries was changed. For builds through the Software Parts Manager interface, the default workspace path now includes the operating system and compiler version number, and ends with a directory named for the build type code. For command line builds through CBM, the directory named for the build type code is added, but not the version number of the operating system and compiler, which depends on information supplied by the user through the SPM interface. You can override the default path with the -w argument to rwspm.

So for Tools.h++ compiled for Microsoft Visual C++ version 5.0 on Windows NT version 4.0 with a build type of 3s, the default workspace path generated by a command line build would be

   <rw_root>/workspaces/WINNT/MSVC/3s

while the default path generated by an SPM build would be

   <rw_root>/workspaces/WINNT4/MSVC50/3s

To make the path generated by a command line build compatible with builds you might later perform through the SPM interface, use the -w option to specify a workspace path with version numbers.

The implications for IDEs and existing applictions are that include paths and link library information will need to be updated in the makefiles for existing applications, and in the setup information of IDEs. For more information on these issues, consult the build guide for your product in the <rw_root>/htmldocs directory.

Case 2: Upgrading a pre-SPM (May 1997) build

If you are upgrading a pre-SPM Rogue Wave part through CBM, the same considerations of different library and workspace locations apply as described above for Case 1. In addition, the library names generated by CBM do not match those of pre-SPM builds. Application makefiles and IDE settings will need to be updated to the new library names and locations.

An alternative solution, of course, would be to change the name of the library built by CBM to the old library name, and to move it to the old location (or, in Unix environments, to create a link from the old library to the new). We would advise you, however, to update your makefiles and environments so that when you obtain the Software Parts Manager graphical interface you can take full advantage of Software Parts Manager's benefits for managing and building your Rogue Wave parts.

Change in build type codes for the Standard C++ Library

Also beginning with the November, 1997 release, the build type codes associated with the Standard C++ Library were made compatible with products built on the Standard C++ Library. Previously, the Standard C++ Library used build codes 0 through 7 based on the true but inconvenient assumption that the Standard C++ Library was not dependent on itself, but all products built on the Standard C++ Library used codes 8 through 15. The Standard C++ Library now uses codes 8 through 15, which avoids inconsequential but troubling error messages during the build of dependent products. Note, however, that if you rebuild the Standard C++ Library with the new version of CBM, the library name will be different, which may require changes to makefiles or IDE settings.

CBM User Guide
Index