[Rock-dev] [TESTING NEEDED] Autoproj prerelease (1.13.0.b1)

[Sylvain Joyeux]

This prerelease contains the versioning branch, which will provide the
technical means for the next Rock release (and hopefully many more
after that). As such, it would be great if as many rock developers as
possible could try it out (as well as as many adventurous rock users
;-))

Apart from the usual bunch of bugfixes, some important changes are
getting into this release. They are described in more detail below:
 - retry behaviour
 - versioning support
 - autoproj log
 - testing support
 - forcing the build of excluded packages

But first, the usual installation instructions:

-- for a one-time install in an existing bootstrap
   source env.sh
   gem install --prerelease autoproj autobuild
-- to install in an existing bootstrap, and let autoproj update with
new beta/rc versions
   source env.sh
   AUTOPROJ_USE_PRERELEASE=1 aup --all
   Note that the AUTOPROJ_USE_PRERELEASE flag has to be explicitely
set only once, autoproj will remember the setting. Set it to zero once
to clear it in autoproj's configuration.
-- to bootstrap, add the 'dev' option as first argument to the bootstrap script
   wget http://rock-robotics.org/autoproj_bootstrap-dev
   ruby autoproj_bootstrap-dev dev git https://github.com/rock-core/buildconf

Retry behaviour
=============
autoproj will retry a lot less than before, especially when running
git commands. The only commands that should retry are the ones
accessing the network.

Versioning Support
===============
An overrides.d/ directory can be created in the main autoproj
configuration. This directory can hold override files, whose format is
the same than the overrides: section of overrides.yml. e.g.:
  - tools/autobuild:
    branch: master

These files are loaded in alphabetical order. One would usually want
to prefix them with two numbers to make the ordering clearer
(00-initial.yml or 99-last.yml)

The use of overrides.yml for this purpose is still supported, but deprecated

-- New commands:
  autoproj versions --save=autoproj/overrides.d/10-thisandthat.yml
     outputs a "version file" , i.e. a file compatible in the
overrides.d format that "pins" the packages passed on the command line
(or all packages if none are given)
  autoproj tag
     saves the current versions in overrides.d/50-versions.yml as a
subcommit of autoproj/'s HEAD and saves the result as a tag. This does
not change the current working copy
  autoproj commit
     saves the current versions in
autoproj/overrides.d/50-versions.yml and commits the result. This
modifies the working copy.

In addition to these new commands, autoproj's update behaviour has
been modified to NOT reset a branch because of commit pinning. One has
to provide the --reset option to get the old behaviour. However, one
will get a "cannot update" error if the pinned commit is not merged in
HEAD and there is a fork situation.

Autoproj log
=========
Autoproj now saves "under the hood" a versions file each time autoproj
update is executed. The resulting log can be accessed with autoproj
log, and an older revision can be checked out with autoproj reset.
Example:

$ autoproj log
  autoproj@{0} 81 minutes ago /home/doudou/dev/rock/autoproj/bin/amake --all -k
  autoproj@{1} 5 weeks ago /home/doudou/dev/rock/autoproj/bin/aup randward
  autoproj@{2} 5 weeks ago /home/doudou/dev/rock/autoproj/bin/aup randward ()

(Note that the amake --all -k line is there because a package needed
to be checked out)

$ autoproj reset autoproj@{0}

Testing support
============
Autoproj learns about a testing target. Tests can be enabled and
disabled on a per-package basis, and dependencies can be made
test-specific using the <test_depend .../> tag instead of the <depend
.../> tag. The test facility can be accessed through the 'autoproj
test' subcommand (see autoproj test --help). It will now be possible
to avoid building usually pretty costly test suites for packages whose
tests are not required.

Overriding package exclusions
========================
One can now force building an excluded package (i.e. because of for
instance a programmatic exclusion) by adding it explicitely to the
manifest. For obvious reasons, this works only on a
package-per-package basis (no metapackages).

Sylvain