Building and distributing fw externals

These directions start from scratch by building EVERYTHING.

Notice that we are using the native compiler.

<product-dir> is the fully qualified path to your external packages directory.

<fw_externals-version> will be one of two different forms:
  • vx_y_z for ups
  • x.y.z for the source code and distribution tarballs
These are generic instructions. Use these instructions in conjunction with Building on machines other than Scientific Linux
  • We expect to support this, but this is a secondary priority effort
  • These notes list problems we are finding. Once a problem is fixed, it will no longer be listed.
  • The build scripts need to be changed to use /bin/bash instead of /bin/sh
  • There is a problem building python 2.4 on Ubuntu 10

Bootstrap a new product directory

Building a distributable ups

Setup the build environment

1. Start with a fresh login.

source <product-dir>/setup

2. For the purposes of this build, make sure that the PRODUCTS variable only points to <product-dir>. This variable is used in the build scripts.

bash: export PRODUCTS=<product-dir>
tcsh: setenv PRODUCTS <product-dir>

3. Get and unwind the fw_externals source code tarball:

tar xzf fw_externals-<fw_externals-version>-source.tar.gz

Build products with no dependencies

  • The build order is very important. Several products rely on the existence of other products.
  • We start by building those products which have no depencencies except the existence of ups.
  • Within this group, products can be built in any order, and in parallel.
  • We recommend that you look at the various log files after they are created.

Build python

cd $PRODUCTS/python/v2_4_2b/
./ >& log.buildPython &

Build cmake

cd $PRODUCTS/cmake/v2_6_4/
./ >& &

Build clhep

cd $PRODUCTS/clhep/v2_0_4_7
./ >& &

Build cppunit

cd $PRODUCTS/cppunit/v1_12_1
./ >& &

Build libsigcpp

cd $PRODUCTS/libsigcpp/v2_2_7
./ >& &

Build products which depend only on cmake

Build gccxml

cd $PRODUCTS/gccxml/v0_7
setup cmake
./ >& &

Build products which depend only on python

Build scons

cd $PRODUCTS/scons/v1_3_0a
setup python v2_4_2b
./ >& &

Build boost

cd $PRODUCTS/boost/v1_34_1
setup python v2_4_2b
./ >& &

Getting root

See Building fw_externals v0_5_0

Declare fw_externals

  • fw_externals is simply a container used to setup the other products.
  • The build simply defines fw_externals in the ups database.
  • However, the other products need to exist first or this step will fail.
cd $PRODUCTS/fw_externals/v0_5_0

Distributing fw_externals

Verify that ups recognizes all the products

  • List all the products in <product-dir>
ups list -aK+

Make sure that you can setup fw_externals

setup fw_externals <fw_externals-version>
  • This should succeed without complaint.
  • You may wish to check things with, for instance, "which cmake", etc.


  • Get rid of ups-upd-bootstrap-noarch.tar.gz and fw_externals-<fw_externals-version>-source.tar.gz
  • Also, the source code tarball contained two source code tarballs which are now redundant.
rm -f <product-dir>/ups-upd-bootstrap-noarch.tar.gz
rm -f <product-dir>/fw_externals-<fw_externals-version>-source.tar.gz
rm -f <product-dir>/scons/v1_3_0a/scons-1.3.0.tar.gz
rm -f <product-dir>/boost/v1_34_1/boost_1_34_1.tar.gz

Build the distributable ups tar file.

  • Some definitions used to name the tarball:
  • version: usually written as, for instance, 0.5.0 instead of v0_5_0
  • os: sl4, sl5, etc.
  • architecture: noarch, i686, or x86_64
  • compiler: gcc34, gcc41, gcc45, etc.
  • For general distribution, we allow people to define their own <product-dir>, so we build the tarball from inside <product-dir>
  • Note that there are two hidden directories, .updfiles and .upsfiles, which need to be included explicitly
cd <product-dir>
tar czf ../fw_externals-<version>-<os>-<architecture>-<compiler>.tar.gz .u* .
  • If you are using a <product-dir> which will have the same name everywhere, you can just tar at that level:
cd <product-dir>/..
tar czf fw_externals-<version>-<os>-<architecture>-<compiler>.tar.gz <product-dir>
  • We tar up everything since the noarch part is very small compared to the architecture specific part.
  • Note that <product-dir> will also contain at least framework, and possibly other products. These instructions are just for the products required to build framework.

Getting a prebuilt tarball