[ANNOUNCE] x-jhbuild 0.3

[Dirk Wallenstein]

X-JHBuild-0.3
#############

X-JHBuild is a framework for building and working with X.org modules.
It makes use of JHBuild and is specialized for working with modules that
use Git as VCS.

http://sourceforge.net/projects/x-jhbuild/
http://www.x.org/wiki/XjhBuild

Navigation Convenience:
=======================
The navigation function has now support for command line completion, and
can clone a repository when it does not exist.  It is possible to
configure aliases for modules, but only the navigation function knows
about them currently.

Configuration Convenience:
==========================

Forks, Clones, Personal Trees:
------------------------------
It is now possible to select a fork of a main module by means of a
simple configuration option.  For example to use ~vignatti/xorg-server
in the place of xorg-server, all that is required is this configuration
snippet:

    [module.xorg-server]
    fork = vignatti/xorg-server

There is always only one repository of one kind (xorg-server in this
example) in the set of active modules.  All distributed subcommands,
with a few exceptions, act only on the active modules, in terms of the
main module id.  The advantage is that you can use the main module-ids
everywhere and just inject a different repository by making a small
change to the configuration.

Aware of forks are the navigation function, and the status plug-in when
used with the new option '--forks'.  There is the fork management
plug-in 'fork-man' which can display information about forks in a way
similar to 'modinfo', as well as download inactive modules.  You can,
for example, easily iterate over all paths of inactive, checked-out
repositories. 

There is now a moduleset (xjh-forks.modules) with a large set of fork
definitions.  This is the default moduleset now.

New Configuration Options:
--------------------------
There are new configuration options that allow to make modifications to
the dependencies of a module, specify tags, and pick only some of the
modules to work with (like a reverse skip setting).

The need to edit a moduleset has been largely reduced by this.  For
example the xkbcommon.modules moduleset is now obsolete and the same can
be accomplished with this configuration section:

    [module.xorg-server]
    fork = krh/xorg-server
    branch = xkbcommon
    deps-add = libxkbcommon

Likewise the wayland.modules moduleset is obsolete and can be replaced
by this configuration:

    [buildconfig]
    modules = wayland
    modules-filter = kbproto dri2proto libxkbcommon libdrm mesa cairo wayland

    [module.cairo]
    autogenargs = --enable-gl

    [module.mesa]
    autogenargs = --enable-gl --enable-gles2

The moduleset repository at [1] contains further example configurations.

To have module specific configuration in one section and not spread out
across diverse subsections of 'buildconfig', there is the new top-level
configuration section 'module' which is a container for subsections that
apply to one particular module each.  The buildconfig subsections
that apply to commit selection and module specific build configuration
moved into this section and the old sections have been deprecated.
The affected sections are branches, module-[c]makeargs, and
module-autogenargs, as well as the augmentation versions of those
sections. 

Benefits:
---------
Overall these changes will make overriding a module in a moduleset a
rare exception.  Fork and revision selection, as well as build
configuration can now exclusively be done in the configuration without
burying it in a swath of dependency graph descriptions.
Modulesets can now be a stable and persistent description of
repositories.  In particular, hiding checked out repositories when
combining modulesets should never be necessary.

Smaller Changes:
================
- It is now possible to recognize unspecified options in a multi-type
  configuration section.  This is useful if every specified value
  overrides a default that is determined by other means.  There is the
  special string representation '<unspecified>' for such cases.
- The patched JHBuild that is being used here, has its own repository
  now [2] and is referenced by a new submodule.
- There can be configuration templates in the directory
  '~/.x-jhbuild/config-templates' that will be used as repository
  configuration when specified as argument to the '-c' option of 'init'. 
- Configuration files in the token and template directories can have an
  optional '.xjhrc' suffix.

Dirk Wallenstein (20):
      init: Add support for configuration templates
      repogroup: Abstract handling of xjh-dir file locations
      Remove patch that modifies JHBuild defaults
      JHBuild update
      moduletraits: Fix cmake trait generation
      configsection: Recognize unspecified options in multi-type sections
      prompt: Extract function that finds the repogroup root
      repogroup: Move filename definitions into repogroup.py
      cwdmodule: make get_cwd_repo_root_dir() public
      gitaccess: Don't assert a valid HEAD reference
      buildconfig: Support envvar expansion in cmakeargs
      Support an optional configuration file suffix '.xjhrc'
      modaccess: Add functions that facilitate working with forks
      jhbuild update: More versatile configuration
      init: Change default moduleset to xjh-forks
      Add the fork management plug-in 'fork-man'
      Navigation upgrade
      status: add support for forks
      prompt: Display sub-paths below ./people/ as module id
      x-jhbuild-0.3

[1] http://x-jhbuild.git.sourceforge.net/git/gitweb.cgi?p=x-jhbuild/modulesets-xorg;a=summary
[2] http://x-jhbuild.git.sourceforge.net/git/gitweb.cgi?p=x-jhbuild/jhbuild-mod;a=summary

-- 
Greetings,
Dirk