OSDL Build system

Overview

OSDL and Ceylan, its helper library, are designed to be portable, hence to be run onto several platforms. We tried to choose the most relevant technologies so that multiple platforms could be managed seamlessly, knowing that for rather uncommon or specific architectures the build system had to be tailored on a per-platform basis: requesting a unique build process to be able to take them all into account would be a tough task with no real added-value.

What we mainly expect of an overall build system is to be able to:

• help the day-to-day development process, by providing a user-friendly, non error-prone environment, which includes smart build messages, dependency tracking and paranoïd checkings
• generate the library/application from it sources, on every platform supported by this system, henre including per-platform detection and configuration
• generate the means of testing the developments, i.e. the set of unitary and overall tests supplied with them
• generate the associated documentation, again from the sources, including project informations, user's guide, tutorials, reference manual and full API documentation
• install all the application-related content appropriately, including of course the headers, the libraries, the documentation, the examples, the tests and the main application itself, if any
• produce some informations and statistics about the current developments, such as the line number count
• create archives, both for back-up and distribution (releases)

Setting a build system is a necessary but dull task. What we aim at, more generally, is to make a safe bet on a standard system which will not slow us down, will not restrain or torment us daily, and that will remain used and maintained for a long while by a strong community.

There is only one means of knowing whether a platform is supported thanks to the build system: it is to actually take a source release of the developments and to try to build it from scratch. Therefore one should have access to every platform to support, which is detailed in our quality section, in the testing subsection.

Candidates & choices

• home-made Makefiles: this was the solution we started with. Our somewhat advanced GNUmakefiles took in charge all the tasks detailed above. The drawback was that it was a non-standard way of build, hence hindering portability and needing some efforts to be understood by new developers. Moreover, the configuration step was not separated from the build itself, thus slowing down the whole rebuild process while in development phase. It was quite a nice system though
• Cmake [Cross-platform Make] is an interesting system, but maybe not mature enough for our needs yet. It would require the user to have it to build from sources, and the maintainers to write specific rules to detect pre-requesites, whereas one could hope to have them readily available with systems already more widely spread
• SCONS [Software construction tool] suffers from somewhat similar drawbacks, including the need of having Python
• Jam [homepage] is little known, we did not want to take a risk with it
• the GNU Autools have finally been chosen for the UNIX-like builds, there are detailed below

The Autotools

They are powerful yet dreadfully complex. Their benefits should not be overlooked, they are vey well described in the Autotools Handout listed below. It tooks us hours of efforts to support them, and some issues (as having to generate our configure.ac (!) or having platform-agnostic installed headers) could not be overcome satisfactoringly.

Autotools links

• The Autotools Handout, by Alexandre Duret-Lutz
• The Autobook, a.k.a. the autotools bible, a pleasant and useful reading by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor
• The GNU Automake manual [other source]
• The GNU Autoconf manual
• The GNU make manual
• Using Libtool for GNU
In mid-1999, an official Autoconf macro archive was established on the World Wide Web by Peter Simons in Germany. The archive collects useful Autoconf macros that might be useful to some users, but are not sufficiently general purpose to include in the core Autoconf distribution. The URL for the macro archive is:
• Useful Autoconf macros archive

Please react !

If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!