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 _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com