Converting a package to ctbuild


Gustaaf Brooijmans 1/18/99
 

This manual describes one way to convert an existing package to ctbuild.  A full description of ctbuildcan be found at http://www.bonner.rice.edu:80/adams/cbuild/ (and FAQ on the use of ctest and ctbuild in D0 can be found at http://www.bonner.rice.edu/adams/cvs/d0/ctbuild/doc/d0faq.html). In a few short words, it's (an implementation of) an interface for building software which bypasses the need for the user to edit (GNU)makefiles.
There's also a general introductory tutorial to software for RunII (the "episodes", which use ctest - ctest is very similar to ctbuild from a user's point of view).

An example of what follows, applied to the popular "analyze" package, can be found on d02ka at
/d0chb/home/room1/gusbroo/tau/tmp, under packagename analyze.

Getting Started:

To make the conversion, you probably want to create a new release area:
>newrel -t xxx tmp
Here xxx is a version (you can take xxx=test), and tmp is the name of the area we're going to work in.
>cd tmp
Now, to make life easy, we're going to make a local copy of the package:
>addpkg -h  mypackage
Here mypackage is the name of the package you want to convert.
The next step is to set up the ctbuild version of the package:
>ctnewpkg -l  mypackagectb

Note: For the moment (1/21/99), ctnewpkg still installs the ctest GNUmakefiles - you will have to edit
>xemacs mypackagectb/GNUmakefile &
and replace the line
include ctest/component.mk
with
include ctbuild/srt/srt.mk
 

Ok - now let's get to work:

Phase one : Header and src directories (the strict minimum)

Phase two: Integrated tests

Phase three: binaries

Finally, when everything is tested, get rid of the non-cbuild version:

>rm -rf mypackage
>mv mypackagectb mypackage
>cd include
>rm mypackage
>ln -sf ../mypackage/mypackage mypackage

Don't forget to edit the LIBRARIES file in test and bin to change mypackagectb to mypackage.

To finalize it all, clean up the cvs repository before commiting the changes.  The easiest way to do this is probably to compare your new version of mypackage with the one in $BFDIST/releases/$BFCURRENT/mypackage.
Step through each directory (mypackage, mypackage/src, etc.) and cvs remove all the files that are in $BFDIST/releases/$BFCURRENT/mypackage but not in mypackage; next cvs add all the files that are in mypackage but not in $BFDIST/releases/$BFCURRENT/mypackage: in directory mypackage that should be at least LIBDEPS (see note below),SUBDIRS and VERSION, in mypackage/src that should be COMPONENTS, OBJECT_COMPONENTS, LIBRARIES, all the xxx_t.cpp files, etc.

When you've done all this, and cross-checked everything is fine, issue a
>cvs commit mypackage

Note on LIBDEPS: At this moment, ctnewpkg does not create a LIBDEPS file.  It is however very important that all packages have this file asap (deadline has been set at 9 Feb 99).  It should contain the names the package directly depends on.  For example, if the package uses HepTuple, it should contain HepTuple but not the packages HepTuple depends on (Exceptions etc.) - unless these are directly called as well.

Done!

As usual, questions, corrections, comments -> feel free to contact me.


GB 1/21/99