Continuous Integration server for C++ - What about library dependencies?

Question

I am currently researching a good setup for a continuous integration server which would build various C++ applications for several Linux distributions.

My primary question is how other users here have handled the differences in system libraries between Linux distributions?

While it might be relatively easy to build direct dependencies such as UI libraries along with an application, "indirect" dependencies such as glibc look like a big pain if they had to be built alongside the application every time. I am therefore thinking of moving the actual build execution into a separate virtual machine for each distribution, e.g. using rlogin to run the commands. My goal is to prevent binary incompatibilities between build-machine library versions and those deployed in the target distributions.

Does anyone here have any experience with such a process and could tell if the above sounds like a feasible approach?

Beggary

I would like to see a good answer to this question. In addition to original question, I would like to know how I can cross compile for mingw on Linux also (I use mingw in Windows). Also, I use the Qt framework and QTestLib for unit testing. Thanks! – Sunburst

I also would like to see a good answer to this question. IMHO, this goes to "configuration management" issues as each module "couples" to other modules, and by linking a lib, that means you implicitly must link the up-stream libs. Since that requires lib-versioning-limitations, this problem gets complicated quickly (e.g., DLL-hell, or RPM-hell). Indirect dependency propagation is essential, in the context of bounded compatible versions. – Spectrometer

Answer 1

We use Jenkins (Contiguous Integration) and CMake (build system) for this purpose. Jenkins is similar to Buildbot, i.e. it also has buildmaster and buildslaves. Currently I have setup 8 slaves to build for 4 different platforms (FC8, FC10, FC12 and Windows 7). We build both debug and release binaries, so I dedicated one slave for each platform and build type.

As for the third party libraries like Qt & Boost, I compiled them on each platform and checked them into a separate repository.

@esavard: We use CMake 2.8 to do cross compilation, I have not used minigw but a quick google search indicates that it is possible. Here is a link to a tutorial to cross compile for Windows on Linux using CMake and miniGW.

I have not used Buildbot and cannot comment on its features but thought I should mention an alternative that we are currently using.

Hope this helps.

Dagmar

Do you think I could achieve something similar using qmake instead of CMake (we use qmake right now and we were using Scons before that)? – Sunburst

I have not used qmake, so I cannot say for sure how it would work. Here is a link that talks about cross compiling Qt apps for Windows on Linux with qmake. Scons is also very good, I tried it before opting for CMake. We went with CMake because of its support for multiple IDE's We have people using Eclipse, Code::Blocks, VS05, VS10 and Emacs. Only problems I ran into were to support Pre-Compiled Headers using CMake. – Dagmar

Answer 2

Buildbot has the notion of buildmasters and buildslaves.

A buildmaster takes care of displaying the web GUI, sending email, triggering builds, and other housekeeping. The buildslaves wait on the buildmaster and when commanded perform builds.

We have buildbot set up to build on a number of different platforms, some of them VMs, and it's working well for us.

Hohenlohe

Answer 3

Certainly buildbot and many virtual machines is the way to go with this. We have VMWare ESX server hosting many build slaves which overnight compile our application. The application is then tested on another virtual machine (not the build slave and just having a default OS install) to verify that it works and all dependency's are packaged.

The nice thing I would like to do is make the testing run time phase an automated step but I haven't been given the time to do that yet.

Stendhal