LOFAR User Software

This page appears to conflate the LOFAR system software repository ( with the USG/LUS repository ( Please treat any instructions below with caution until that has been sorted out!


  1. Software packages

Organization of the repository
|-- code
|   |-- branches
|   `-- trunk
|   |   |-- devel_common
|   |   |-- data
|   |   |-- external
|   |   `-- src
`-- documents
    |-- branches
    `-- trunk

Checking out code

You can obtain a working copy of the source code by running (Registration is needed to access the repository; January 2013)

  • using Subversion…
    svn co code
  • using Git…
    git svn clone code

    Please be aware though that this will retrieve to complete backlog of all changes, so you might rather use

    git svn clone -r <revision> code
    cd lofarsoft
    git svn rebase

    where <revision> is either a specific revision number or the word HEAD, which refers to the latest available version.

In case you not only want a working version of the source code, but also of the various documents:

mkdir usg
cd usg
svn co code
svn co docs

Note: Release versions of the Pulsar tools (as used on CEP2 and CEP3) can be obtained from the URL (for example):

svn co src

This will download the whole tree, including the pulsar tools.

Bootstrapping your working copy

Once the checkout from the central repository has completed, you are left with a directory structure as described above. The next step now is to get to the point where it is possible to build (and subsequently install) packages in the software collection…

As the LUS uses the CMake cross-platform makefile generator to handle the configuration of the code base, the most important thing to check is whether or not a suitable version of CMake is available on your platform – this check is carried out through the bootstrap script in the top-level directory of the working copy:


The the main job of the bootstrap script is to check whether or not a recent enough version of CMake is installed on your system; if the found installation is too old or not available at all, a build from the provided sources is triggered and the resulting executables will be installed into “release/bin” (which of course then should be in your PATH).

Updating your working copy

As with the case of retrieving your working working copy from the central repository, this step is very much depending on the tool used locally for version control:

  • Subversion : Change back to the top-level directory of your working copy and and run
    svn up
  • Git : Depending on your choice to deal with upstream changes, you might change back to the master branch of your working copy before running
    git checkout master
    git svn rebase

    If however you prefer to directly merge the upstream changes into your feature/development branch, you simply run

    git svn rebase

    In either case ensure there are no uncommitted changes – either add and then commit them or stash them, before pulling in the upstream changes.

  • Last modified: 2017-03-08 15:27
  • (external edit)