The 'flavors' in rock denote certain sets of packages that have reached a certain degree of stability. See this page for more information.

This page describes how the flavor system is implemented in rock's autoproj configuration

Current scheme

The flavor system is based on the definition of a ROCK_FLAVOR configuration variable. This variable is then used in the source.yml to select the branch based on the flavor. The user-chosen value can be overriden externally for a single build by setting the ROCK_FORCE_FLAVOR environment variable (this is used by rock-status to generate the status pages).

Based on this variable, two things happen:

Package declaration w.r.t. flavors

The basic change in the flavor system is that the package branches in source.yml need to be set to $ROCK_FLAVOR.

Moreover, one needs to declare in which flavors a given package should be made available. This is declared in the autobuild file by including a package definition in a in_flavor block:

in_flavor "next" do
  cmake_package "drivers/gps"

The flavor are inclusive (i.e. a package that is in the "next" flavor will be in "master" but not in "stable"). Moreover, the master flavor is a default flavor, i.e. packages that are in none of the in_flavor blocks will be made available in master.

in_flavor does not hide a package definition. It only tells the system in which flavor a package is available by default in a given package set. For instance, in the package set "rock" if I do

in_flavor "next" do
  cmake_package "pkg1"
cmake_package "pkg2"

Then the layout

  - rock

will build only pkg1 in "next" and both pkg1 and pkg2 in "master". However, the package pkg2 is still declared in "next", so one can do

   - rock
   - pkg2

to build both packages in "master". The rock.all metapackage also allows to build all packages declared in a package set, regardless of the flavor:

   - rock.all

If it is needed to completely hide autobuild configuration code from some flavors, use only_in_flavor:

only_in_flavor "master" do
  # this will be executed only when the master flavor is selected

Other considerations

Packages cannot be imported from a given branch if they are not included in the corresponding flavor (to avoid breaking a build by using $ROCK_FLAVOR for a branch while the package is only defined in master). For instance, if I declare

in_flavor "master" do
  cmake_package "new/package"

and have in source.yml:

  - new/package:
    gitorious: rock-new/package
    branch: $ROCK_FLAVOR

Then the configuration code, while in the "next" flavor, will switch the branch back to master during configuration time (and warn the user).

A do-not-commit hook is automatically installed for git-based packages whose branch is "next" or "stable", to avoid having people develop on next without their knowledge. The hook allows development if the ROCK_UPDATE_NEXT environment variable is set to 1.


The implementation is in the rock.base package set. It is two-sided:

  • init.rb defines the data structures and methods like #in_flavor
  • overrides.rb handles the declarations, changes the definition of metapackages, installs the git-do-not-commit hook and switches "wrong" branches back to master.

For reference: branch-based handling

Another scheme has been initially tried. In this scheme, the root autoproj configuration would be common, but the package sets would be setup on a per-flavor basis and loaded using the $ROCK_FLAVOR branch.

The main issue with that scheme is that it is very hard to mix flavors: as soon as one is using the "next" flavor of the rock package set, he does not have access to the packages that are only defined in "master". The advantage, obviously, is that it is in principle not possible to break next by breaking the autobuild configuration (since the next autoproj configuration changes only during the updates of next).

Last modified 10 years ago Last modified on 08/15/11 16:47:12