Neil Hopcroft

The whole point of a CI server is to do continuous integration, that is making sure everything still works whenever there are any changes upstream as well as any changes to a projects own code. Looking at the dependencies for the octave build, there are a number of things I had to build myself to get the build working on the AWS server I’m using. I have taken that as a list of packages to build in the CI server. The dependencies look like this:

• octave-packages
• octave
• arpack
• fltk
• librsvg
• pango
• mesa
• libxcb
• xorg-macros
• qhull
• qrupdate

None of these projects appear to be under significant development at the moment so I have set them to poll for updates daily, and the dependencies are set up within Jenkins such that any rebuild will build all of the projects that depend upon it.
There is one significant omission from this list: QT. Although I found a number of places that give links to the QT 4.8 active development branch, none of them are working for me.

The nature of the Octave project is that it is a large project with lots of dependencies, this is one of the aspects that attracts me to it as a project to consider contributing toward. This does, however, mean that building it is quite complicated.
My aim was to set up a CI build in my Jenkins server, running on the AWS cloud, to launch a build whenever there was a code change. There are a few challenges here, firstly not all of the dependencies are available within the AWS yum repository, secondly not all of the dependencies are correctly checked by the configure script, leaving unexpected build failures, finally the versions of those things available with the yum repository are not necessarily recent enough to satisfy the dependencies.
My approach to missing yum dependencies has been to obtain the source code for the missing items and build and install them as required, arguably it would have been better to find a more complete yum repository, and perhaps that is what I would do next time – I didn’t know the extent of the missing dependencies when I set out.
As for the unexpected build failures, there isn’t really much you can do except to fix them as you encounter them. There is probably some scope for updating the configure dependencies to better reflect the actual dependencies, but that is beyond what I am aiming to do here.
The build itself is quite simple and takes the form:

./bootstrap
./configure
make
make check
make install

The process I used was to get the build steps into Jenkins as early as possible, then run the builds there – that way there is a repeatable process and a good way of recording build outcomes. The following are some of the dependencies I encountered while getting the build set up.
Things available in the AWS yum repository:

• gperf
• flex
• bison
• gnuplot
• gcc-gfortran
• libpcre
• fftw3
• glpk
• curl
• blas
• lapack
• suitesparse
• ncurses
• readline
• freetype

Things built from source:

• icotool
• makeinfo
• texi2dvi
• librsvg
• qhull
• hdf5
• arpack
• mesa
• qt
• qrupdate
• fltk

For most of these packages the default installation path was /usr/local, which highlighted some configuration problems in the AWS system I was using, the newly built version weren’t being picked up by pkg-config and the libraries weren’t being found. I hacked around these problems by copying the .pc files to a pkgconfig directory on the path and specifying /usr/local/lib/ as the LD_LIBRARY_PATH when launching the builds.