- Table of contents
- How to build a release using buildFW
How to build a release using buildFW¶
Overview of buildFW - Comparison with mrb¶
This article describes how to manually build a uboonecode release using the buildFW script. Like mrb, buildFW runs on top of cetbuildtools. Individual packages are built using cetbuildtools script "buildtool." As with mrb, instructions for building individual packages are contained in each package's CMakeLists.txt and product_deps files. The result of the build is a ups product for each package. Unlike mrb, buildFW builds are controlled by a top level build configuraiton file, rather than a top level CMakeLists.txt file (see below for more information). BuildFW can be invoked without access to any preexisting ups products area. Dependent ups products are downloaded from scisoft, or built from source.
Obtaining the buildFW script¶
Download the latest version of the buildFW script from the scisoft tools area .
The buildFW command is invoked as follows.
buildFW [-t] -b <basequal> -s <setqual> <proddir> <buildtype> <bundlespec>
The options and arguments of this command are as follows.
- -t - Option "-t" instructs buildFW to make ups distribution tarballs, in addition to installing ups products in <proddir>.
- -b <basequal> - The base qualifier (e.g. "e17" or "c2") instructs buildFW which compiler to use.
- -s <setqual> - The set qualifier corresponds to the "s" qualifier of some of larsoft's dependent products (such as ifdh_art). This option has no effect on the build per se, but only affects the name of the product manifest created by buildFW.
- <proddir> - Ups product area (absolute path) where ups products should be installed. Product manifest and distbribution tarballs (if selected by option "-t") are also installed in this directory.
- <buildtype> - debug or prof.
- <bundlespec> - The bundle specification has no effect on the build, but only affects the name of the build configuration and product manifest. For uboone suite builds, the bundle specification should be of the form "uboone-<verision>." Note that the "<version>" field of the bundlespec should be a ups-style version (including initial "v," fields separated by underscores).
The build configuration file.¶
BuildFW is controlled by a top level build configuraiton file. Among other things, the build configuration file contains the versions of each package being built.
The the name and location of the build configuration file are not directly specified on the buildFW command line, However both are derived from the <bundlespec> argument.
If <bundlespec> is specified as "uboone-<version>," the name of the build configuration file would be "uboone-cfg-<dotversion>." That is the word "cfg" is inserted between the bundle name and the bundle version, and the version string is converted into "dot format" (e.g. vxx_yy_zz becomes xx.yy.zz).
It is not the purpose of this article to describe how to construct a build configuration file. The build configuration file will normally have been pre-uploaded to scisoft, and buildFW will look for it there. The build configuration file url has the following form.
If a release has previously been built by the MicroBooNE release manager, the build configuration file should always be available on scisoft. The build configuration file for each release is produced as a side effect of an initial mrb build, based on a template stored in uboonecode/releaseDB/uboone-cfg.in. Uploading this build configuration file to scisoft is the responsibility of the release manager.
In addition to making ups products and binaries, buidFW produces a manifest of the entire build. Each invocation of buildFW produces a single manifest, which is a text file that is left in the top directory of the ups products directory. The manifest is normally uploaded to scisoft, along with distribution tarballs, by the release manager. The manifest is used by other scisoft tools, such as "pullProducts."
Making local modifications¶
It is possible to make local modifications to the build configuration or to package sources, and buildFW can pick up these location modifications.
Making local modifications to the build configuration file¶
BuildFW first looks for the build configuration file in the products directory when buildFW is invoked. If buildFW doesn't find the build configuration there, it will attempt to download a copy from scisoft into the products directory, which copy will be left there. The local copy of the build configuration can be edited for subsequent invocations fo buildFW.
Making local modifications to package sources¶
When buidFW builds a package from source (after not having found prebuilt binaries on scisoft), it checks out sources into the ups products package directory, in subdirectory "src." On subsequent invocations of buildFW, sources will not be checked out again if there is a "src" subdirectory. Thus, it is possible to edit already checked out sources, e.g. in case of compilation errors, and to invoke buildFW again.