CONTIBUTOR(S): Steve Vinoski Hewlett-Packard Company e-mail: vinoski@apollo.hp.com Bob Chase Atria Software e-mail: chase@atria.com ====================================================== ********************************************************** ************** THIS IS UNSUPPORTED SOFTWARE ************** ********************************************************** ********************************************************** * Atria makes no representation that the descriptions * * and software code contained in this document will * * not infringe on existing or future patent rights, * * copyrights, trademarks, trade secrets or other * * proprietary rights of third parties. The * * descriptions contained herein do not imply the * * granting of licenses to make, use, sell, license or * * otherwise transfer Atria products described herein. * * Atria disclaims responsibility for errors which may * * appear in this document, and it reserves the right, * * in its sole discretion and without notice, to make * * substitutions and modifications in the products and * * practices described in this document. * ********************************************************** # (c)Copyright 1992, 1993 Hewlett-Packard Company. All Rights Reserved. # # This material is distributed with no warranty whatsoever. Neither the # author nor Hewlett-Packard Company takes responsibility for any # consequences of its use. # # Permission to copy without fee all or part of this material is # granted provided that the copies are not made or distributed for # direct commercial advantage and the Hewlett-Packard copyright notice # appears in all copies. To copy otherwise requires a fee and/or # specific permission. ------------------------------------------------------------------------------ T0014: Easier-to-integrate version of ClearMake C++ Build Technique, for managing C++ type repository (defmap) files as derived objects ------------------------------------------------------------------------------ EASY-TO-INTEGRATE CLEARMAKE/C++ BUILD TECHNIQUE OVERVIEW The ClearMake/C++ Build Technique illustrated here is based on the one in T0013. The purpose of T0014 is to make it easier to integrate the Build Technique with existing makefiles, including Makefiles that are not based on Make inference (suffix) rules. We provide two solutions in this package for building C++ programs. They are called CM-safe and Incremental Build. The CM-safe solution always deletes the program's ptrepository directory whenever the program target is rebuilt. This avoids the problem where template objects do not get rebuilt when compiler options change (C++'s build avoidance scheme is unable to detect this difference). It also eliminates CR-chaining - a problem which interferes with sharing derived objects across views. Also in the single user single view case, it makes it hard to understand the configuration via commands like "catcr" and "diffcr". Because not all template objects are rebuilt when the ptrepository directory is not removed, the configuration record for the program target ("foo") has sub derived object references to pre-existing template objects, which was itself produced by a build of the same program target ("foo".) Some developers may not consider sharing across views important during parts of the development cycle, when changing compiler options does not happen often and re-instantiating templates during every build is time- consuming and unnecessary. The second solution, Incremental Build, does not delete the ptrepository directory when the program target is rebuilt. This means some template instantiations from the last program rebuild may be reused. They may be reused inappropriately if build scripts have changed. Also, their reuse results in CR-chaining, which interferes with sharing derived objects across views. The following section describes in more detail the handling of the ptrepository directory. The basic issue in building C++ programs with ClearCase is described in this excerpt from the paper entitled "Using the cfront Automatic Template Instantiation System With ClearCase" (available in T0013): 4.1 defmap Files as Derived Objects Whenever cfront encounters the use of a template in a source file, it updates the defmap file stored in the ptrepository directory. ClearCase detects this updating activity because the defmap file is written to its VOB file system. Therefore, when cfront is used with clearmake, the defmap file becomes a derived object of the source module being compiled. Whenever the defmap file is updated, it effectively nullifies the results of all builds that previously modified it, meaning that each source file containing templates will be recompiled each time clearmake is invoked for it. Similar problems for linked executables are caused by the _lock, _instfile, and defmap.old files, also created in the ptrepository directory by cfront for various purposes. A description of the basic solution is described in these excerpts: 5.1 Making Separate defmaps For Each Object File To prevent a single defmap file from being modified during the compilation of all C++ source modules in a directory, it is necessary to use the -ptr option of cfront. The following command line results in the creation of the defmap file in the "foo.temp_ptrep" directory: CC -c-ptrfoo.temp_ptrep foo.cc This approach results in the creation of a separate type map derived object file for each source module that uses templates. 5.2 Combining Separate defmaps Unfortunately, creating separate defmap files for each object file as shown above results in another problem: cfront template instantiation no longer works because the single defmap file expected by cfront does not exist. The obvious solution to this problem is to recombine the contents of the various type map files before invoking CC to link. Due to the simplicity of the syntax of the type map file, a program that combines type maps is not difficult to write. This directory (T0014) contains Makefile fragments, and shell and perl scripts, which are designed to be integrated with existing Makefiles. It also includes example C++ source files and a few sample Makefiles which builds a program from them. To build the example, copy the directory into a ClearCase VOB, set your working directory there, and run "clearmake -v". perl is not included here - if necessary, it may be obtained by sending email to chase@atria.com . Users must supply their own C++ compiler. FILES foo.cc queue.cc queue.h stack.cc stack.h Example C++ source files Makefile Example Makefile which builds program 'foo' from source files using the CM-safe solution. Uses cxx.mk. Makefile.incbuild Example Makefile which builds program 'foo' from source files using the Incremental Build solution. Uses inc_cxx.mk. Makefile.sgi Variation of Makefile to use with SGI C++ using the CM-safe solution. Uses cxx.mk To obtain a version using the incremental build solution, replace the use of cxx.mk statement with inc_cxx.mk. make_ptrep perl script, referenced by makefile build script (a variation of make_defmap). make_ts_cache perl script, referenced by makefile build script. atria_* /bin/sh and perl scripts, used to manipulate defmap files before and after C++ translations occur. cxx.mk makefile definitions and rules for building C++ programs using the CM-safe solution. inc_cxx.mk makefile definitions and rules for building C++ programs using the Incremental Build solution.