Building MeqTrees (old autoconf-based build system)

This applies to repository revisions prior to 6972. As of 6972, a new cmake-based build system is available and the old system is no longer supported (i.e. bugs will no longer be fixed, so it's bound to break at some point.)

Create a variants file for your machine

A variants file describes your local build environment (compilers, AIPS++, etc.) Skip this step if you're on lofar9/10/birch/cedar, since a working variants file is checked into cvs. Otherwise, use variants.dylan as a starting point: 

  $ cd Timba/autoconf_share
  $ cp variants.dylan variants.YOUR_HOST_NAME

Now check the variants file to make sure the compiler specification (CXX), Qt and aips++ paths all match your system. (Have no fear, if they don't, you'll learn about it soon enough anyway). Typically, you will need to edit these lines:

This tells the build system how to locate the 'gnu3' compiler, and what flags to use. If you're using gcc-4.x (the default on most systems by now), add something like:

Note that 'gnu3' and 'gnu4' are merely labels for build variants that are later matched up to build directories (see below). You can define any number of different build variantas with different compilers and flags.

Depending on your python version, you may also need to edit this line:

Note also the use of CXX=ccache\ /path/to/g++ in the standard variants files. This compiler specification assumes you have ccache installed (and you really ought to, as it makes rebuilds a helluva lot faster.) If you don't, just give the direct path to the compiler instead: CXX=/path/to/g++

Bootstrap the Timba build environment

    $ cd ~/Timba
    $ ./bootstrap
      # (watch messages go by...)
    $ mkdir -p build/gnu3_debug    # or perhaps gnu4_debug
    $ cd build/gnu3_debug
    $ ../../lofarconf
      # (watch messages go by...)
    $

This also creates a build directory and runs configuration in it.

NB: if using an aips++ version older than ~ July 2006, and Timba repository version prior to 4390 (02/01/2007), you may need to supply the --with-old-lsqfit option to lofarconf. If you're not sure, try building without this option first, and if you get compile errors in MeqNodes/Solver.cc, reconfigure with this option. Timba versions from 4390 automatically detect the version of aips++, so this flag is no longer needed.

For an optimized build variant - see below - you would do: 

    $ cd ~/Timba
    $ ./bootstrap               # if you previously did a 'debug' build, this call is not necessary
      # (watch messages go by...)
    $ mkdir -p build/gnu3_opt   # it may already exist
    $ cd build/gnu3_opt
    $ ../../lofarconf
      # (watch messages go by...)
    $

A note on build variants

The directory name gnu3_debug specifies a build variant. Given such a directory name, lofarconf will match up 'gnu3' with a compiler definition from your variants file, and 'debug' with a standard set of debugging flags. Likewise, 'gnu3_opt' produces an optimized build, and 'gnu3_prof' produces a build with profiling information. By judicious manipulation of the variants file, you can make other builds as necessary.

Building the beast

If any software has been updated, you can bring your local copy up-to-date with: 

    $ cd ~/Timba
    $ svn up

Then, this command (re)builds the entire system: 

    $ cd ~/Timba/build/gnu3_debug
    $ make
      # (Go out to lunch)
    $

NB: if you get a bunch of linker errors during the build, try re-running lofarconf with the --with-old-libtool option, then make clean and make. Some older versions of libtool simply refuse to put libraries together properly, so this option enables a workaround.

Speed up your builds with distcc

On lofar9/10/birch/cedar, you may harness the power of distributed compilation by setting up distcc: 

    $ mkdir ~/.distcc
      # copy over my distcc hosts file:
    $ cp ~oms/.distcc/hosts ~/.distcc
    $ export CCACHE_PREFIX=distcc    # this assumes bash, tcsh use setenv
    $ cd ~/Timba/build/gnu3_debug
    $ make -j10
      # and hope it works -- get a cup of coffee instead of lunch

Installing the products

The build system supports a make install command (copy-install) to copy the products to some specific lofation. For an actively-developed system, this is exteremely time-wasting and inconvenient, and our install targets are usually broken.

Instead, we use the symlinking-in-place method. Under Timba/install/symlinked-xxx, there is a whole tree of symlinks pointing to various binaries and Python modules dispersed through the Timba source tree. The xxx referes to build variants (debug, optimized, etc.)

First, go into Timba/install and create the following symlink: 

  $ cd Timba/install
  $ ln -s symlinked-gnu3_opt current

The current link points to the build of Timba currently in use, in this case symlinked-gnu3_opt, which in turn refers to the build targets directly in the source tree.

Setting up paths

This probably belongs in your .bashrc or .cshrc.

New setup (as of March 2007)

* Set the $TIMBA_PATH variable to point to your Timba directory (default is ~/Timba).

* source $TIMBA_PATH/install/timba-init.sh (or .csh, if that's your preference)

This will point your paths to $TIMBA_PATH/install/current. You can switch to a different build by saying, e.g., _timba-setup symlinked-gnu3_opt at the shell prompt. You can also add this command to .bashrc.

Old setup (prior to March 2007)

* Add the following directory to your $LD_LIBRARY_PATH:

* Add the following directory to your $PATH:

* Set the $PYTHONPATH environment variable to

Now, to run the meqbrowser, simply type meqbrowser.py

Note that this all assumes that scripts and binaries may be found under ~/Timba/install/current, so make sure your "current" symlink is correct.

BuildingTimba/ActualBuildOldBuildSystem (last edited 2009-09-17 15:09:57 by OlegSmirnov)