GENESIS: Documentation

Related Documentation:

The Developer Package

Maintaining many software projects quickly becomes a lot of work. It also makes it difficult for new people to step into software development, for example, because dependency tracking between software components must be done manually. The Developer package automates the management of multiple software projects. It automates updates to local source code, synchronization between distributed repositories, compilation, testing and installation, packaging and releases, serving monotone repositories and other things. Besides monotone it also has experimental support for integration with mercurial.

The Developer package provides developer utilities that comply with GENESIS development standards. At its core is the neurospaces_build script used for automated software installation and maintenance on a configurable set of software packages. Because this script has many options, the most common operations are provided using simpler frontends. Other scripts are related to version identification of the software, source code documentation comments, testing, and release management. The following sections include simple and detailed examples.

Downloading the Developer Package

The Developer Package can be downloaded from the GENESIS package archive website.

Simple Examples

Simple examples can be used by developers who do not want to know about the intricate details of the Developer tools. Most developers fall into this category. Software developers and laboratories who have added their own private software components should be OK using the simple examples and can skip reading the detailed examples.

Detailed Examples

The detailed examples provide:


Some utilities currently depend on monotone for source code version control due to their configuration. It is possible to work with other version control systems.

Main script

Front-end Developer Scripts

The following utilities take optional arguments of “--regex” to select the packages they operate on, and “--verbose” to run the command in a more verbose mode. They follow the order of the Developer Workflow. The information they return are determined by the configuration of the Developer package.

Note: These Developer package commands are run from a command line prompt, i.e. outside the GENESIS environment.

  1. Write/Update Code:
  2. Document Code API:
  3. Build/Check:

    The neurospaces_upgrade command makes the local source code up to date with the source code served by the remote servers. It thereby combines steps 1 and 3 explained above. This command is similar in operation to the invocation of the commands neurospaces_uninstall, neurospaces_pull, neurospaces_clean, neurospaces_update, neurospaces_install

  4. Regression Testing:
  5. Internal/Public Release:
  6. Integrate Software Components:

Detailed Examples of the Release Procedure

After putting a Tag on the code, you first must check if the package can be built from the tarball. The autotools distcheck target does this (see below). An additional check is to build the tarball, put it somewhere on your filesystem, and then build the check target from the tarball. For example, first build the tarball and put it somewhere on your filesystem (e.g. /tmp/uploads):

   neurospaces_build --developer --verbose --upload-server --no-install --regex studio

Then build the check target from the tarball:

   neurospaces_build --verbose --check --regex studio --src-tag python-5  --src-dir /tmp/uploads --verbose --verbose --unpack --no-install

In a one line summary you need to insert a --tag, and --distcheck the current code, then make them available on Sourceforge. In one line of code:

   neurospaces_build --developer --distcheck --verbose --tag network-5 --src-tag network-5 --upload-server --verbose

If you don’t want to do the upload, for a single package:

   neurospaces_build --tag network-5 --distcheck --regex ’model-container’ --developer --verbose

If that works, you then want to do the upload:

   neurospaces_build --src-tag network-5 --upload-server --regex ’model-container’ --developer --verbose

The --verbose option is there to let you know what is going on during this lengthy procedure.

The same procedure is used to build a release of either individual or all packages. An official public release is made available for download on Sourceforge. Intermediate releases are for internal use only.

Because official releases are built using automake’s distcheck target, they must pass the tests of the package (on the machine used for the build). So they are considered to be alpha releases (ie. internally well tested).

The release procedure normally checks for package correctness using the automake distcheck target, meaning that both install and uninstall targets work and are each other’s complement. Official releases must always succeed on this target. Intermediate releases can fail.

Other Examples