Neil Hopcroft

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.