The progress on JHBuild has continued (although I haven't done much in
the last week or so). Frederic Peters of
JhAutobuild fame now has a CVS account to
maintain the client portion of that project in tree.
One of the other things that Frederic has been working on is support for
building Perl modules (which use a Makefile.PL instead of a configure
script). His initial patchworked fine for tarballs, but by switching
over to the new generic version control code in jhbuild it was possible
to support Perl modules maintained in any of the supported version
control systems without extra effort.
One of the other suggestions for jhbuild that came up a while ago was to
make it "eleventy billion times faster". In essence, adding a mode
where it would only rebuild modules that had changed. While the idea has
merrit, the proposed implementation had some problems (it used the
output of "cvs update" to decide whether things had changed).
I'd like to get something like this implemented, preferably with three
Build everything (the current behaviour).
Build only modules that have changed.
Build only modules that have changed, or have dependencies that have
The second option is obviously the fastest, and is a useful option for
collections of modules that should be API stable. The third option is
essentially an optimisation of the first option. For both the second and
third option, it is necessary to be able to tell if the code in a module
has been updated. The easiest way to do this is to record an identifier
for the tree state, and the identifier is different after an update.
The identifier should be cheap to calculate too, so will probably be
dependent on the underlying version control system:
CVS - a hash of the names and versions of all files in the tree.
maybe (can be constructed by reading the CVS/Root,
CVS/Repository and CVS/Entries files in the tree).
Subversion - a combination of (a) the repository UUID, (b) the
path of the tree inside the repository and (c) the youngest revision
for this subtree in the repository.
Arch - the output of "baz tree-id".
Bzr - the working tree's revision ID.
Darcs - a hash of the sequence of patches representing the tree,
Tarballs - the version number for the tarball.
On a successful build, the ID for the tree would be recorded. On
subsequent builds, the ID gets recalculated after updating the tree. The
new and old IDs are then used to decide on whether to build the module
or not, according to the chosen policy.