cmsBuild Cfg files and Options

Configuration file specific options:

  1. priority: priority for a given section in a cfg file. Lower values get executed earlier.

Build command specific options:

  1. compilingProcesses: same as --compiling-processes, this specifies the number passed to the "-j" option of make
  2. workersPoolSize: same as --workers-pool-size, specifies the number of parallel threads used by cmsBuild?
  3. systemCompiler: same as --use-system-compiler, see build documentation.
  4. doNotBuild
  5. tag: same as --tag, tells cmsBuild to append tag to packages which have the same group, name and version of another one but that use a different spec. The system will also add and increasing integer number which reflects the number of times a package has been successfully built. A description on how the whole tagging works can be found below the last item is this list.
  6. testTag: same as --test-tag, always adds a tag to a given package, even if the combination of group, package name and package version was never built before. This option has to be used in conjunction with the "test" option and it's useful for example for test packages which could always have a "-testXXX" appended to their name. A description on how the whole tagging works is

Automatic rpm version tagging

A little bit of history

The old version of cmsBuild (AKA, while it was able to spot when a given spec file was modified and could rebuild it if explicitly requested, it was unable to notice that indirect dependencies were changed and you could end up with weird behaviours:

  1. The installation of a given package could have brought in multiple version of given tool.
  2. A given tool might have not been rebuilt even if the spec was changed.

To work around this problem we usually did the dependency checking by hand, adding a tag (e.g. -CMSxyz) whenever a given package needed to be rebuild and to all the dependent packages. All this was error prone and had to be done by hand.

Enter the new cmsBuild

The new version of cmsBuild actually solves this problem by calculating a unique hash per package build which takes into account the spec file of the package and those of all its dependencies, including indirect ones, plus the default values/preamble for the spec file sections (which are embedded in cmsBuild code itself). This means that when a package is modified, not only its hash is different but also the one of all its dependent packages is. Problems 1. and 2. are now non-issues. The hash is stored inside the rpm and if no option is specified is appended (like the old tags) to the version of the package. You could end up with packages like


Human readable package names

While this solves a problem, the package naming it's now obviously non-intuitive. To solve this problem the new cmsBuild adds two new options: --tag and --test-tag. The first one allows the package builder to specify a human readable tag (e. g. cms) which gets mapped to the hash of a given, correctly built, package. so if you were to build gcc using:

cmsBuild <global-options> build --test-tag --tag cms gcc The system rather than building:

external+gcc+4.0.0-722763f2066901692b0b4d9148ab06bf will build

external+gcc+4.0.0-cms and will keep the association between 722763f2066901692b0b4d9148ab06bf and cms so that, whenever the hash calculated for gcc matches the one above, cms is used instead. The --test-tag option is used to always add the tag, even if it was the first time that a given package version was build (and therefore, in principle, no tag was actually necessary). If we now modify and rebuild gcc, using the same command as above, the system will notice that the hash for it is actually different and will automatically call the new package:


A few remarks on the tagging implementation

A given hash to tag relationship is not actually global, but local to the remote repository used and to the local build area. Which means that two persons working in two different work are could get the same tag for different hash of the same package. What keeps the system consistent is the upload to the central repository, which is serialized and will therefore spot the fact that someone has already used a given tag when the second comer will try to upload his/her package. In that case, the system will complain and the developer will be asked to use the deprecate-local command in order to remove all the conflicting builds from his local area and then build again. This time the system will spot upfront the other conflicting package (because it's in the same repository) and provide a non conflicting tag for it.

Upload command specific options:

  1. uploadPort: same as --upload-port, see upload documentation
  2. syncBack: same as --sync-back, see upload documentation.

Bootstrap specific options:

  1. onlyOnce: execute the bootstrap only if not already done.

Generic options:

  1. pretend: same as --pretend. Do not actually execute but just
  2. assumeYes: same as `--assume-yes, cmsBuild does not prompt the user for choice and always assumes that the answer to all its question will be will be yes.
  3. debug: same as --debug.
  4. trace: same as --trace.
  5. doNotBootstrap: do not execute the bootstrap.
  6. use32BitOn64: same as --use-32-bit-on-64, prepend all the commands by the linux32 command. This must be used consistently. If you use it for the build command you must also use it for the upload command.

-- ElizabethSextonKennedy - 12-Mar-2010

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2010-03-12 - ElizabethSextonKennedy
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback