Version 1 (modified by sylvain.joyeux, 8 years ago) (diff)


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 FLAVOR configuration variable. This variable is then used in the source.yml to select the branch based on the flavor.

However, special handling is required for packages that are available in e.g. master but not next. These are handled the following way:

  • the flavors in which a package is available are defined in the autobuild file. This is done 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 not be in "master"). 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".

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


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 $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 the