A prototype build system for CASA using SCons

See also

• Introduction to SCons

I have designed a prototype implementation of a build system for CASA based on the SCons tool. The design is sketched out here, together with instructions on how to actually invoke the build and an incomplete list of the outstanding issues

Note

This system is experimental and not the official way of building CASA. Note also that to guarantee correct results, the scons invocation must be made twice.

Let me know of any problems

The code

The main version of the code for this build system is contained in a bzr branch, together with the remainder of the CASA system. This work is rooted on revision 8827 (on /v2/active) of CASA from the NRAO SVN repository.

I would be very happy to place the bzr branch somewhere public if people would like to try it. In the mean time, you can look at the patch to the tree which implements this system: http://www.mrao.cam.ac.uk/~bn204/nvc/20091109/build-improve-proto1.diff

Directory structure

This SCons implementation uses the option to create the build in a directory separate from the source code. This makes sure there is no pollution of the source tree by compilation by-products and also allows very easy manual clean, namely the “rm -rf” command.

In the present prototype the entire build is made in the build/test sub-directory of the root. Multiple builds are possible here, useful for example for optimised/debug build or cross-compilation to a different platform, all from the same source root. (I did do a little cross-compilation project with SCons some time ago, targeting Linux and Windows using mingw and it worked nicely).

Generating IDL files

The generated IDL files, and their auxiliary XML files (see Interface Description Language (IDL) files) are generated very easily using custom builders that call the saxon tool. All of the generated files are placed in directory named xmlcasa/gcode.

The static IDL files also copied (hard-linked actually) there. With all of the files there, it is possible to make a single monolithic invocation of CCMTools and generate the full set of bindings.

Note however that since the auxiliary files must be in the working directory of the ccmtools executable, they are copied there at the time of execution of the ccmtools file and then removed at the end.

Inference of targets created by CCMTools binding generation

The targets of CCMTools are generated by capturing the output of one invocation of ccmtools to a file named “gcode/cadac.flist” (oops, I misspelled that, should fix it) and then parsing this file in the scanner.

Because of the two stage nature of the build-process (see Two stages of operation), the build always uses the flist file generated in the previous build, because the targets and sources are determined before any actions are executed. This means that two invocations of the build process are necessary to guarantee a correct build. When building in a clean directory, two stages are always necessary.

Code cleanups

Version information

In the original version of casa, the entire C++ source file that contains the version number/date of CASA is auto-generated. I have replaced this with a mostly fixed file, which can take version number/date as predefined macros, as is standard in most software systems. See code/utils/version.cc.

Header-only files

There are a few header-only ”.h” files, i.e., they declare classes which are also fully defined (because of inline methods) in the header. In original CASA they do not have corresponding .cc files. I have added these .cc files to enable an easier and more consistent build.

QT-compilation

The built-in QT builders for SCons only handle QT3 projects, but with the addition of the supporting file “qt4.py” the support for QT4 is very good.

Specifying QT

A typical call to SCons:

QTDIR=/home/bnikolic/d/p/cs /home/bnikolic/d/p/cs/bin/scons  casacoreroot=/home/bnikolic/d/p/cs PKG_CONFIG_PATH=/home/bnikolic/d/p/cs/lib/pkgconfig

Why QTDIR?

SCons does not autmoatically propagate the variables from envirionment. But it looks like it does need QTDIR in order to detect the QT installation in first stages. Remainder of pick up is using pkg-config and the PKG_CONFIG_PATH defined option

Actually invoking the build process

Build:

QTDIR=/home/bnikolic/d/p/cs /home/bnikolic/d/p/cs/bin/scons \
casacoreroot=/home/bnikolic/d/p/cs \
PKG_CONFIG_PATH=/home/bnikolic/d/p/cs/lib/pkgconfig \
ccmroot=/home/bnikolic/d/p/cs

To debug the SCons build process:

QTDIR=/home/bnikolic/d/p/cs /home/bnikolic/d/p/cs/bin/scons -k \
casacoreroot=/home/bnikolic/d/p/cs \
PKG_CONFIG_PATH=/home/bnikolic/d/p/cs/lib/pkgconfig \
ccmroot=/home/bnikolic/d/p/cs xmlcasa --debug=stacktrace \
--tree=all --tree=status --debug=explain

Outstanding issues

1. Only a single stage build of the CCMTools bindings is supported, i.e., a change in any of the IDL files triggers a rebuild of all components. This is because some of the targets generated by CCM depend on all sources being specified while others do not (see also Generation of casac_python.cc file)
2. Two builds are required for proper operation since the dependencies and targets that are made from the IDLs are dynamically generated
3. Version info isn’t currently filled into the file.
4. Library names and organisation is not exactly the same as the old CASA build
5. Currently many libraries are built from the root SConscripts; using more subsidary SConscripts (as already done for xmlacasa for example) may be more elegant