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. ------------------------------------------------------------------------------ T0013: ClearMake C++ Build Technique - for managing C++ type repository (defmap) files as derived objects ------------------------------------------------------------------------------ CLEARMAKE/C++ BUILD TECHNIQUE OVERVIEW The ClearMake/C++ Build Technique illustrated here was originally contributed by Steve Vinoski of the Distributed Computing Program of the Hewlett-Packard Company. This directory contains a PostScript file containing a paper, originally written by Steve, and edited slightly by Atria Software, which describes the issues involved in using ClearCase to build C++ programs that use templates, and describes a technique which can be used to most effectively apply ClearCase to C++ builds. The basic issue in building C++ programs with ClearCase is described in this excerpt from the paper: 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 Once this compilation has finished, the defmap file in that directory can be renamed and the foo.temp_ptrep temporary repository can be deleted: mv foo.temp_ptrep/defmap foo.ptmap rm -rf foo.temp_ptrep When these commands are combined into a single clearmake build rule, the result of compiling the source file foo.cc under clearmake is: Will store derived object "/vob/foo/foo.o" Will store derived object "/vob/foo/foo.ptmap" 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 contains example Makefile, source files and perl scripts which illustrate the technique described in the paper. To run the example, copy the directory into a ClearCase VOB, set your working directory there, and run "clearmake -v". This example has been tested with SparcWorks C++ on Solaris 2.2, and with the HP C++ compiler on HPPA/HPUX9. 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 ccase_cfront.ps PostScript file for paper written by Steve Vinoski: "Using the cfront Automatic Template Instantiation System With ClearCase" foo.cc queue.cc queue.h stack.cc stack.h Example C++ source files Makefile.orig Original example Makefile which builds program 'foo' from source files. This version is written as described in the appendix of the paper. Makefile Slight variation of original Makefile which builds program 'foo' from source files. This version does not depend on /bin/ksh, and it also creates the ".ptrep" directory for the program if it does not already exist. make_defmap perl script, referenced by makefile build script make_ts_cache perl script, referenced by makefile build script