Command Reference

JHBuild Manual

JHBuild uses a command line syntax similar to tools like CVS:

jhbuild [global-options] command [command-arguments]

The global JHBuild options are:

-f, --file config: Use an alternative configuration file, instead of the default, ~/.jhbuildrc.
-m, --moduleset moduleset: Use a module set other than the one listed in the configuration file. This should be a relative path if the module set is located in the JHBuild moduleset folder, or an absolute path if it is located elsewhere.
--no-interact: Do not prompt the user for any input. This is useful when leaving a build unattended, in order to ensure it is not interrupted.

Command specific options are listed below.

3.1. autobuild
3.2. bootstrap
3.3. build
3.4. buildone
3.5. checkbranches
3.6. dot
3.7. gui
3.8. info
3.9. list
3.10. rdepends
3.11. run
3.12. sanitycheck
3.13. shell
3.14. tinderbox
3.15. update
3.16. updateone

The autobuild command is used to automatically build the modules specified in the configuration file, and then upload the results to JhAutobuild.

jhbuild autobuild [--autogen] [--clean] [--skip=module...] [--start-at=module] [--report-url=reporturl] [--verbose]

The --autogen, --clean, --skip and --start-at options are processed in the same way as for the build command.

--report-url=reporturl, -r reporturl: This option specifies the JhAutobuild URL which JHBuild should report to
--verbose, -v: This option causes JHBuild's output to be more verbose

The bootstrap command is used to install a set of build utilities required to build most modules (eg. autoconf, automake, etc).

jhbuild bootstrap

Internally, bootstrap is implemented using the same code as build, using the bootstrap.modules moduleset.

Look at the build command documentation for available options.

The build command is used to build one or more packages, including their dependencies.

jhbuild build [--autogen] [--clean] [--dist] [--distcheck] [--no-network] [--skip=module...] [--start-at=module] [--tags=tags] [-D date] [--no-xvfb] [--try-checkout] [--no-poison] [--force] [--build-optional-modules] [--min-age=time] [module...]

If no module names are given on the command line, then the module list found in the configuration file will be used.

-a, --autogen

Always run autogen.sh before building modules. By default, autogen.sh will only be called if the toplevel makefile is missing. Otherwise, it relies on the package's makefiles to detect if configure needs to be rebuilt or rerun.

-c, --clean

Run make clean before building modules.

-d, --dist

Run make dist after building modules.

--distcheck

Run make distcheck after building modules.

-n, --no-network

Do not access the network when building modules. This will skip download or update stages in a build. If a module can't be built without network access, it will fail.

-s, --skip=module,...

Ignore the named modules when following dependencies to expand the list of modules to be built.

--tags=tag,...

Ignore modules that do not match any of tag when following dependencies to expand the list of modules to be built.

At the moment modules are automatically attributed a tag with the name of the module set they sit in.

-t, --start-at=module

After expanding the list of modules to build, start at the named module rather than at the beginning of the list. This is useful if the build was interrupted for some reason.

-D date

If the underlying version control system supports it, try to update the source tree to its state at the given date before building. The date string should be in ISO format.

-x, --no-xvfb

Run graphical tests on the actual X server rather than in a simulated Xvfb

-C, --try-checkout

If the build fails, and the version control system supports it, force a checkout and run autogen.sh before retrying the build.

-N, --no-poison

If one or more of a module's dependencies failed, this option forces JHBuild to try to build the module anyway.

-f, --force

Build the modules even if policy tells it is not required.

--build-optional-modules

Some modules, listed as optional dependencies, may not be required to build the target module, this option inncludes them nevertheless.

--min-time=time

Skip modules installed more recently than the given relative time; the time string format is a number followed by a unit, with the following units being supported: seconds (s), minutes (m), hours (h) and days (d).

Example: --min-time=2h will skip modules that have been built less than two hours ago.

The buildone command is similar to build, but it does not use dependency information to expand the module list. It is useful for quickly rebuilding one or more modules.

jhbuild buildone [--autogen] [--clean] [--distcheck] [--no-network] [-D date] [--no-xvfb] [--force] [--min-age=time] module...

The --autogen, --clean, -d, --distcheck, --no-network, -D and -x options are processed in the same way as for the build command.

Unlike the build command, at least one module must be listed on the command line.

The checkbranches checks the modules in GNOME Subversion have the correct branch definition. For example, if modules are marked as not having branched, JHBuild checks this is true.

jhbuild checkbranches [--branch=branch...]

--branch=branch, -b branch: Specify the branch to check

$ jhbuild -m gnome-2.20 checkbranches
libgnomecanvas is missing branch definition for gnome-2-20
$

The dot command generates a file describing the directed graph formed by the dependencies between a set of modules. This file can then be processed using the GraphViz software to produce a nice diagram.

jhbuild dot [--soft-deps] [--clusters] [module...]

If no module names are given on the command line, then the module list found in the configuration file will be used.

The --soft-deps option will add dotted lines from the modules to their soft dependencies. The --clusters option will group modules from metamodules together.

The output of this command can easily be piped to the dot utility to generate a PostScript file:

$ jhbuild dot modules | dot -Tps > dependencies.ps

Or a PNG image:

$ jhbuild dot modules | dot -Tpng > dependencies.png

Figure 1 Sample JHBuild dot output

The gui command starts a graphical interface to JHBuild which can be used to select modules to build and change some options.

jhbuild gui

The gui graphical interface is rendered using GTK, so some extra support libraries will be required

The info command is used to display information about one or more modules.

jhbuild info module...

The command prints the module name, type, dependencies, dependent packages, and the time it was last installed with JHBuild. It may also print some information specific to the module type, such as the CVS repository or download URL.

If there is no module specified the command will print information about all the modules defined in the module set.

The list command is used to show the expanded list of modules the build command would build.

Run with the -a option, this command will list all the modules known from your moduleset configuration regardless of the build dependency.

jhbuild list [-a] [-r] [-s] [--tags=tags] [--list-optional-modules] [module...]

If no module names are given on the command line, then the module list found in the configuration file will be used.

-a, --all-modules: List all the modules
-r, --show-revision: If a particular module is being checked out on a branch, show the branch tag name with the module name.
s, --skip=module,...: Ignore the named modules when following dependencies to expand the list of modules.
--tags=tag,...: Ignore modules that do not match any of tag when following dependencies to expand the list of modules to be displayed.
--list-optional-modules: Some modules, listed as optional dependencies, may not be required to get to the target module, this option inncludes them nevertheless.

The rdepends command is used to show the reverse-dependencies of a module.

jhbuild rdepends [module]

--dependencies: Show dependency path next to modules.
--direct: Limit display to modules directly depending on given module.

The run command is used to run an arbitrary command using the same environment that JHBuild uses when building modules.

jhbuild run [--in-builddir] program [argument...]

If using JHBuild to build GNOME, this command can be useful in X startup scripts.

--in-builddir=module: Run the command in the build directory of the specified module.

The sanitycheck command performs a number of checks to see whether the build environment is okay.

jhbuild sanitycheck

Some of the checks include:

That the checkout and install prefixes are writable.
That some of the required build tools are installed.
That some commonly used macros are available in the search paths of the aclocal commands associated with the various versions of automake.
That the XML catalog contains the DocBook DTD and stylesheets.

The shell command starts the user's shell with the same environment as JHBuild uses when building modules.

jhbuild shell

This command is roughly equivalent to the following:

$ jhbuild run $SHELL

The tinderbox command is similar to build, but writes all terminal output to HTML files suitable for publishing on a website. It can be used to set up systems similar to Mozilla's Tinderbox, or Debian's Buildd.

jhbuild tinderbox [--autogen] [--clean] [--no-network] [--output=directory] [--skip=module...] [--start-at=module] [-D date] [-C] [-N] [module...]

The --autogen, --clean, --no-network, --skip, --start-at, -D, -C and -N options are processed the same as for build.

-o, --output=directory: The directory to write the HTML build logs.

The update command is similar to build, but only performs the download or update stage for modules without building them.

jhbuild update [--skip=module...] [--start-at=module] [--tags=tags] [-D date] [module...]

The --skip, --start-at, --tags and -D options are processed the same as for build.

The updateone command is similar to update, but it does not use dependency information to expand the module list. It is useful for quickly updating one or more modules.

jhbuild updateone [-D date] module...

The -D option is processed the same as for update.

Unlike the update command, at least one module must be listed on the command line.

GNOME Documentation Library

Command Reference

3.1. autobuild

3.2. bootstrap

3.3. build

3.4. buildone

3.5. checkbranches

3.6. dot

3.7. gui

3.8. info

3.9. list

3.10. rdepends

3.11. run

3.12. sanitycheck

3.13. shell

3.14. tinderbox

3.15. update

3.16. updateone