X-JHBuild: A thin JHBuild wrapper with plug-ins.

[Matt Dew]

On Tue, May 25, 2010 at 2:01 AM, Dirk Wallenstein <halsmit at t-online.de> wrote:
> X-JHBuild-0.1.3
> ===============
>
> Notable new features:
> ---------------------
> - Diverse moduleset specification forms. Add some convenient forms and
>  aliases, but also re-enable the previously prevented arbitrary
>  specification forms. There is more about that in the default
>  configuration file and the corresponding commit message.
> - Let git-config track the cwd-module-id. Manage the setting with
>  internal commands.
>
> Commit Selection and Workflows:
> -------------------------------
> In an effort to understand the additional (yet uncommented) git branch
> attributes of jhbuild, I cleaned up the update operation somewhat [1]. I
> don't know if the behavior is what most people want (or why it was
> undocumented), and so I wait a bit before attempting to document it
> online. However, this is what is currently available regarding commit
> selection:
>
> Branch switches only take place in an update operation.
> Attributes in the moduleset:
>  'tag' : check this out unconditionally, no matter what branch you are
>        on. It is passed directly to 'git checkout'. (might detach the
>        head; might start tracking a remote branch when used with newer
>        git versions).
>  'revision' : switch to a local branch or start tracking a remote branch.
>        Switch only if the current branch tracks a remote branch, to not
>        disturb your own work (The _update_ command is 'git pull
>        --rebase', so you can base your own work on a remote branch, and
>        select that branch in the configuration file.).
> In the configuration file:
>  'branches' : Override the revision from the moduleset. Otherwise, it
>        has the same behavior as the 'revision' attribute. This is also
>        necessary to override the default branch, which is 'master'.
>
> Now, by means of moduleset inclusion, it would be easy to advertise
> testing modulesets or create a bug-squashing branch with a corresponding
> moduleset.
>
> For example, let's assume there is a bug in xwud and the imaginary user
> 'johndoe' creates an 'xwud' repo with an 'audit' branch, and passes the
> URL of the following moduleset to a user willing to try it (that's
> basically just copy-pasting and setting the revision, module and
> checkoutdir attributes):
>
>  <moduleset>
>    <include href="http://cgit.freedesktop.org/xorg/util/modular/blob/xorg-common-test-base.modules" />
>    <repository type="git" name="git.freedesktop.org"
>                href="git://anongit.freedesktop.org/git/"/>
>
>    <autotools id="xwud">
>      <branch repo="git.freedesktop.org"
>                revision="audit"
>                module="~johndoe/xwud"
>                checkoutdir="people/johndoe/xwud" />
>      <dependencies>
>        <dep package="libX11"/>
>      </dependencies>
>    </autotools>
>  </moduleset>
>
> The autotools tag overrides the general one from the included modules
> file completely.
> The user would just pass the URL of this moduleset to [x-]jhbuild and
> could easily test versions the developer provides, even across different
> modules.
>
> In a same manner tests could be advertised.
>
> Someone who wants to regularly test different parts, could set up a
> special configuration for it, and then simply select a moduleset to
> test. A good thing here is build_policy=updated-deps, which builds only
> the modules that changed, and the modules that rely on a changed module.
> There is a patch at [1] that triggers a build for dirty repos with every
> build-policy. Using this for building reverse dependencies is also much
> better than using the strange revdep-rebuild plug-in -- which is just an
> example.
>
> Plans:
> ------
> - repo-group local config: Similar to git, the configuration could be
>  kept inside the checkoutroot directory of the repo-group.
>  I'd like to minimize code in the configfile, and also would like to
>  avoid forging a configfile for jhbuild. Although jhbuild provides a
>  '__file__' attribute inside of the config file, it's probably not so
>  good to rely on that. However, a repo-group local config would be a
>  nice feature, and so I guess I'll use an additional internal-command
>  'init' that fills in the checkoutroot in that configfile and later
>  ensure that it matches in each run.
>  Additionally this 'init' command could set 'prefix' to a directory
>  below the checkoutroot, maybe 'INSTALL' or similar.
>  A user would just cd to a directory and execute 'x-jhbuild init' and
>  'x-jhbuild build xorg'.
> - x-jhbuild configuration file: For settings, like moduleset location
>  aliases.
>
> Any feedback is welcome.
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=618974
>
> --
> Greetings,
> Dirk

Hi Dirk,
  Nice work on this.    As a newbie, I appreciate it.    Any chance
you have time to update the wiki page with the info in your email?

I'm running jhbuild for the first time now,
Matt