gEDA build system redesign

One of the items on the gEDA "Todos" list as a prerequisite for the 1.6.0 release has been a refactor of the gEDA build system. Instead of using several distributed source archives (one for each major component), it was decided to distribute the gaf suite as a single archive, with one unified build system.

Why?

The advantages of this strategy were seen as follows:

1. The system would be less confusing for new testers or "power" users who want to try out the latest changes in git.
2. The whole suite could be built and tested before installing any files. In the past, it's been necessary to install the libgeda and symbols packages before any of the other packages could be built.
3. It would reduce the labour involved in keeping the version numbers, ChangeLogs, and required dependency checks up-to-date. Maintaining multiple configure scripts in parallel is labour intensive, and there is the ever-present risk of missing one.
4. It would simplify the job of distribution packagers. In the RPM case, it would only be necessary for a packager (like the maintainer of the Fedora Electronic Lab distribution, Chitlesh Goorah) to maintain a single SPEC file, rather than nine.
5. It would simplify building using parallel make (see the -j option to make), which can significantly speed up compiling gEDA on machines with multiple or multi-core processors.
6. It would improve detection of targets requiring rebuilding. This is particularly important for working on libgeda; only changes which affect the public interface require a rebuild of the applications, but it's often hard to keep track of what's changed. What often happens with the 1.4.x build system is that people end recompiling the applications completely just to make sure, at a cost of time and energy.

Approach

The rework had been on the "Todos" list for several months when I started looking into it at the beginning of June 2009 (just after handing in my MEng project), and some ideas came to mind about how the current structure of the build system could be improved.

• One idea that crossed my mind extremely briefly was not to use GNU Autoconf and Automake, but to adopt another build infrastructure. Autotools was retained, because not only is it well known by current gEDA developers, but it has worked well enough for us in the past, and it doesn't require developers or users to install yet another tool in order to be able to compile and install gEDA.
• I had recently been looking at the configure.ac file for DTN2 (the reference implementation for the Delay Tolerant Networking Bundling Protocol), and I noticed that they used a very minimalist, clearly-laid-out configure script will almost all of the configure checks being described in separate m4 files, as self-contained Autoconf macros. This appealed to me, because configure.ac files are often very confusing to a newcomer, and this method offered the potential to make it much, much clearer.

Problems encountered

There were two major problems encountered while carrying out the work.

Firstly, internationalisation of desktop integration files (.desktop files to appear in menus etc., and MIME-type info files to make file browsers show the right icon. In previous releases, intltool has been used to do this, but intltool suffers from a major flaw: it doesn't support more than one gettext domain in a single package, and we would need to use at least three (one each for libgeda, gschem and gattrib).

I was very surprised to find that there wasn't an existing solution to this problem in widespread use. In the end, I had to actually write my own tool from scratch to carry out this task, a 550-line shell script called desktop-i18n. Although enormously hacky, it works remarkably effectively!

The second major problem was in getting the testsuite to pass without gEDA being installed. The number of issues encountered was innumerable (one of my "favourite" examples was the way that libgeda used to call exit(-1) if it couldn't find the gEDA font, even in gnetlist which doesn't need to display any text objects anyway). By a combination of actually fixing bugs (few) and horrible nasty hacks (many), I eventually surmounted this issue too. With this, there were more than a few occasions where I felt like I was banging my head against a brick wall.

Results

On Friday 7th August I merged the "build-system" branch into the main git repository, and the new build system seems to be a genuine and successful enhancement (despite a few minor issues). However, I can hardly believe how much work it took to do!