Problems to be solved:

  1. the current autoproj design splits configuration in multiple files (one file per role). It has been commented that it makes it a lot harder to understand, and grouping configuration in a limited set of files would be better
  2. autoproj/manifest confuses user w.r.t. manifest.xml in the packages
  3. the package sets and the main autoproj configuration have different file structures. It means that (1) we can't reuse one for the other -- i.e. we have to explain the difference and (2) creating first a build config and then migrating it to a package set is work
  4. the naming of directories in remotes/ is currently black magic, and uses symlinks to a hidden .remotes directory.

File structure

Proposal 1 (Sylvain)

To solve 1. and 2., the following new layout is proposed:

  • config.yml: contains the list of package sets to load, the version control and overrides information and the layout. The layout is ignored in package sets. The new imports section would replace the current package_sets: section of autoproj/manifest
  • the current config.yml (which contains the configuration options) is renamed to options.yml
  • config.rb: contains the init, autobuild and overrides code. This file would look like:
# Init code, toplevel code would work too, the block form is provided
# only for consistency reasons
init do
autobuild do
before_build do

Issue when put under version control, the big files will often have conflict (i.e. if one makes a change locally and remotely). It was why, so far, we have one package set per project (for the common stuff) and the main autoproj configuration would be only for the developer. This solution will still work with the new proposal. Another suggestion was to allow having a local.yml or config-local.yml that gets "merged" into config.yml

Proposal 2 (Alex)

  • like Proposal 1 but all information from the new config.yml are merged into config.rb based on a domain specific language.
  • Benefit: Improved error handling, more readable
#Possible example for the proposed config.rb 

#package set section
source :type => "gitorious", :url => "rock-toolchain/package_set"

#add a private package
source :type => "git", name => "my_widget" :url => "git://.../widget.git"

#layout section
install "rock-toolchain/package_set"
install "my_widget"

exclude "gui", "ocl"
move "my_widget" => "sub folder"

on_config do

# Autobuild code
on_autobuild do

# Override code
on_build do

on_cleanup do 

Remote naming

Pros and cons of the current method:

  • pros: the package sets are named the same on every autoproj installs
  • cons: nowhere in the main autoproj configuration there is a way for the user (and for the tool !) to know what is what in remotes/. This is IMO confusing, and mandates quite complex code in autoproj itself.

The following change is proposed:

  • the package_sets section specifies both the name of the package set and the VCS information
  • when listed in autoproj/config.yml, this is the name under which it is going to appear in remotes/
  • when listed in another package set, the following logic resolves the name
    • a source with the same VCS is listed in autoproj/config.yml. This name is used.
    • a source with the same VCS is listed in an already loaded package set. This name is used.
    • the name listed in the config.yml of the package set is used.

Migration strategy

As a migration strategy, the following is proposed:

  • first update of autoproj:
    • config.yml is renamed into options.yml
    • the new naming resolution is implemented
    • warnings are issued when no name is explicitly specified in one of the package_sets/imports sections. autoproj falls back to the current behaviour in these cases.
  • second update of autoproj:
    • names for package sets are mandatory, the .remotes directory is removed.
    • loading of the new config.yml file is implemented
    • warnings are issued for deprecated files and deprecated sections, with a link to a relevant wiki page. Installations that are still using them will still function.
  • third update:
    • remove all deprecated features

The timeline for the three steps of the migration still needs to be defined.

Last modified 9 years ago Last modified on 09/24/12 11:22:24