Changes between Version 2 and Version 3 of WikiStart/Toolchain/Flavors


Ignore:
Timestamp:
08/15/11 16:46:03 (8 years ago)
Author:
sylvain.joyeux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/Toolchain/Flavors

    v2 v3  
    55= Current scheme = 
    66 
    7 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. 
     7The 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). 
    88 
    9 However, special handling is required for packages that are available in e.g. master but not next. These are handled the following way: 
     9Based on this variable, two things happen: 
    1010 
    11  * 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: 
     11== Package declaration w.r.t. flavors == 
     12 
     13The basic change in the flavor system is that the package branches in source.yml need to be set to $ROCK_FLAVOR. 
     14 
     15Moreover, 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: 
    1216 
    1317{{{ 
     
    1721}}} 
    1822  
    19 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. 
     23The 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. 
    2024 
    2125in_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 
     
    2832}}} 
    2933 
    30    Then the layout 
     34Then the layout 
    3135 
    3236{{{ 
     
    3539}}} 
    3640    
    37    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 
     41will 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 
    3842 
    3943{{{ 
     
    4347}}} 
    4448    
    45    to build both packages in "master". 
     49to build both packages in "master". The rock.all metapackage also allows to build all packages declared in a package set, regardless of the flavor: 
     50 
     51{{{ 
     52layout: 
     53   - rock.all 
     54}}} 
    4655 
    4756If it is needed to completely hide autobuild configuration code from some flavors, use only_in_flavor: 
     
    5362}}} 
    5463 
     64== Other considerations == 
     65 
     66Packages 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 
     67 
     68{{{ 
     69in_flavor "master" do 
     70  cmake_package "new/package" 
     71end 
     72}}} 
     73 
     74and have in source.yml: 
     75 
     76{{{ 
     77version_control: 
     78  - new/package: 
     79    gitorious: rock-new/package 
     80    branch: $ROCK_FLAVOR 
     81}}} 
     82 
     83Then the configuration code, while in the "next" flavor, will switch the branch back to master during configuration time (and warn the user). 
     84 
     85A 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. 
     86 
     87== Implementation == 
     88 
     89The implementation is in the rock.base package set. It is two-sided: 
     90 
     91 * init.rb defines the data structures and methods like #in_flavor 
     92 * overrides.rb handles the declarations, changes the definition of metapackages, installs the git-do-not-commit hook and switches "wrong" branches back to master. 
     93 
    5594= For reference: branch-based handling = 
    5695