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:
- The system would be less confusing for new testers or
"power" users who want to try out the latest changes in
git.
- 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.
- 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.
- 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.
- 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.
- 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!
