Instructions for building and releasing CORAL

Preparing the configuration

  1. Preparing the afs release area

    The first step for releasing CORAL is to prepare the directory under afs where CORAL is to be released.

    In case of an internal release this step can be ommitted since all releases are build under
    /afs/cern.ch/sw/lcg/app/releases/CORAL/internal.

    In case of an official release, submit a request via the web form under
    https://spi.cern.ch/login/requestAfsSpaceForm.php
    The page prompts you to specify the project name (choose CORAL from the existing menu) and the version in the form X.Y.Z Within a few minutes a new afs volume will be allocated for the project and mounted under the newly created directory
    /afs/cern.ch/sw/lcg/app/releases/CORAL/CORAL_X_Y_Z

  2. Preparing the external configuration

    Check with SPI which is the LCG configuration for the external dependencies that should be used. For normal releases this is LCGCMT_XX, where XX is an integer number. For testing against a new configuration use LCGCMT_preview or LCGCMT_HEAD.

  3. Preparing the CORAL configuration (define the tags)

    Check out the ReleaseTools:
    cvs -d :kserver:coral.cvs.cern.ch:/cvs/coral co -d ReleaseTools coral/config/ReleaseTools
    and enter the directory
    cd ReleaseTools

    Edit the file coral_config.py
    The first lines specify the CORAL version (CORAL_X_Y_Z) and the LCG configuration tag (LCGCMT_XX).
    The next lines define the packages, tests and the versions (cvs tags) to be used for the release.

    Commit the changes.

  4. Bootstrap the project area

  5. Run the tool coral_prepare_release.py specifying the parent of the release directory.
    In case of an internal release this should be /afs/cern.ch/sw/lcg/app/releases/CORAL/internal otherwise /afs/cern.ch/sw/lcg/app/releases/CORAL:
    ./coral_prepare_release.py /afs/cern.ch/sw/lcg/app/releases/CORAL
    This is going to bootstrap the project area in the correct directory and export the sources.

    In case of errors the output will specify at the end the location of the error logs. In this case once the necessary corrective action has been taken, empty the release directory (but do not remove it!) and re-run the script.

Building the binaries

For each of the platforms to be built perform the following:

  1. Log into an appropriate build server.
  2. Check out, if necessary, the ReleaseTools (use a different checkout for different OS/Architecture system), and run the tool coral_build_release.py specifying the release directory and the platform (OS/Architecture/Compiler).
    For example:
    ./coral_build_release.py /afs/cern.ch/sw/lcg/app/releases/CORAL/CORAL_X_Y_Z slc3_ia32_gcc323
    The tool is going to build all the binaries and refresh the plugin cache.
Note that one can schedule the building of all the platforms in parallel.

The win32 binaries are built on a linux box with wine (and the VC compiler) installed.

Building the documentation

While the build procedures are running it is a good time to update the global documentation.

Finalising and releasing

Patching an official release

In the unlikely event that an official release needs to be patched after the volume has been made read-only by the post-build procedure one should perform the following: