Autobuild/Class Model

From Second Life Wiki
< Autobuild
Revision as of 11:09, 9 March 2011 by Rand Linden (talk | contribs) (→‎Platform)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Class model diagram

Autobuild class model.png

The diagram above describes the for an autobuild configuration usually described in an autobuild.xml file. Below we describe the various components in more detail to clarify how autobuild works and how it should be used.


A configuration is a description which contains all the information needed by autobuild to build and package a unit of work like a library or application. The configuration must specify a package_description that provides information about the package this configuration describes. If this package has dependencies on other packages, they may be added to the installables array which lists prebuilt packages that may be downloaded by autobuild.


As noted in the previous section, the package element describes either a package to be built and packaged by Autobuild or to be downloaded and installed by Autobuild. Minimally a package must specify:

  • name
  • license which describes the license type
  • license_file path or URL to the license itself
  • version string

The package element contains a few more informational fields to provide extra description which may be nice to have like a homepage, description, and copyright.

If the source code for the package is downloadable, the source field should contain a URL to the source repository or download site. The source_type field specifies what kind of repository holds the source; e.g. hg, svn, or some other version control system; and the source_directory specifies where the source should be installed. For packages that should be installed as source and built locally, this is all the information needed. For packages to be installed from prebuilt archives or to specify how to build this package, platform elements need to be added to the platforms map.


A platform element includes the architecture/OS specific information for a package. For a package to be installed from an archive, the platform should contain one archive element. For the package to be built, the build_directory should be specified as the location for any build product.

The manifest list includes paths to any build product that should be bundled into an archive for redistribution. Any files or files matching patterns in this list will be included in the archive generated by the autobuild package command. Include at least one build configuration in the configurations list.

Note that the dependencies field is not currently used, though in the future it could list the specific packages this platform depends upon.


An archive element includes the information needed to download a prebuilt archive. The url field is the download url. If the hash field is specified, it will be used to check the integrity of the downloaded archive. The hash_algorithm field is included to permit future support of other hash algorithms than the default md5 hash.

Build Configuration

A build configuration element contains the commands to actually configure and build the package. Autobuild supports multiple build configurations to permit the building of the package in different ways like, for example, using debug options or release options. The default field is a boolean flag which indicates whether this particular configuration should be built when a user does not expressly choose one when invoking 'autobuild'. The configure and build fields contain executable elements which specify the commands to run for configure and build commands in autobuild.


An executable element contains a specification for a single command to be executed in the platform shell. The command field is the application or executable to be called by autobuild. The arguments array is a list of arguments to be passed to the invoked command and the options field is a list of any options to pass. Because autobuild can only call one executable object, developers will typically create scripts to actually drive the platform dependent build system which then may be called via autobuild.