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
- 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¶
Setup the build environment¶
1. Start with a fresh login.
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:
cd $PRODUCTS wget http://oink.fnal.gov/distro/fw-externals/fw_externals-<fw_externals-version>-source.tar.gz 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.
cd $PRODUCTS/python/v2_4_2b/ ./buildPython.sh >& log.buildPython &
cd $PRODUCTS/cmake/v2_6_4/ ./buildCmake.sh >& log.buildCmake.sh &
cd $PRODUCTS/clhep/v2_0_4_7 ./buildClhep.sh >& log.buildClhep.sh &
cd $PRODUCTS/cppunit/v1_12_1 ./buildCppunit.sh >& log.buildCppunit.sh &
cd $PRODUCTS/libsigcpp/v2_2_7 ./buildLibsigcpp.sh >& log.buildLibsigcpp.sh &
Build products which depend only on cmake¶
cd $PRODUCTS/gccxml/v0_7 setup cmake ./buildGccxml.sh >& log.buildGccxml.sh &
Build products which depend only on python¶
cd $PRODUCTS/scons/v1_3_0a setup python v2_4_2b ./buildScons.sh >& log.buildScons.sh &
cd $PRODUCTS/boost/v1_34_1 setup python v2_4_2b ./buildBoost.sh >& log.buildBoost.sh &
- 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 ./buildFWexternals.sh
Verify that ups recognizes all the products¶
- List all the products in <product-dir>
ups list -aK+
- See example output at Building fw_externals v0_5_0
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¶
- You can copy and unwind your own tarball wherever you need it.
- Tarballs for supported distributions of fw_exernals are at http://oink.fnal.gov/distro/fw-externals/