Experimenting with autotools recursive build for the entire OM-2007 tree

[Rodolphe Ortalo]

Hello,

I spent some time trying to define a build system at the root of the
OM-2007/ hierarchy of the SVN tree to enable a one-step build of the
various components of OpenMoko UI tree. However, I used the autotools
(as opposed to the qmake-based attempts of *.pro files from Mickey
IIUC). I tried that because autotools are already used in the individual
lib or apps subtrees and there are some recursive build possibilities
with autoconf and automake.

Here are the main issues involved:
 I was able to get a working build system that builds openmoko-libs and
most of the examples/ applications [1] using automake and autoconf.
This involves creating a top-level configure.ac that can invoke
sub-directories' sub-packages configure via the AC_CONFIG_SUBDIRS macro.
Of course, you need the associated Makefile.am-s (nearly empty) in the
top directories where there is nothing currently.
 If we want the applications to build against the (just built) libraries
in openmoko-libs, it seems necessary to use the pkg-config "uninstalled"
mechanism, which implies to create a new openmoko-libs-uninstalled.pc.in
in openmoko-libs/ that points to the build tree and to set a search path
for pkg-config to find it in the top-level configure. With this, the
applications are linked against the in-buildtree libraries without
modification of their own configure.ac (nice!).

Overall, this is not very complex and, when running in the build tree,
the top-level configure invokes individual packages configure
seamlessly. (And you finally understand the interest of using configure
-C to cache check results... :-)

However, there are a couple of issues with this approach:
1) for a top-level (autotools-based) build system to run correctly, the
sub-packages trees must be ready to configure. So, it would certainly
necessitates to include configure scripts, etc. generated by autoreconf
in the SVN tree. (Nothing in the autotools can be used easily to invoke
recursively something like autogen.sh, plus it is not appropriate in its
current form as it invokes directly configure in the source tree.) [2]
2) if one sub-package cannot configure (e.g. openmoko-panel-demo failed
to find the right matchbox-panel version on my computer), the top-level
one fails too. I have the feeling that it is not very realistic to try
to add more intelligence to do partial full builds (one would duplicate
in the top level configure.ac checks made in sub-packages) even if they
would be interesting (automatically disable the panel demo and build the
rest in my case).

Overall, it seems to me that such a recursive build system is feasible,
but may be worth the effort only if the development team really wants to
keep each package (each application, libs, icons) truely independent. Is
it really intended that one application will make releases independently
from the OpenMoko libraries, etc.?
If not, with the autotools, it may be as easy to define a single build
system for the whole tree capable of configuring and building the entire
tree. (Currently, it is not so big.) That would guarantee the adequacy
between applications and their (Moko) dependencies, at the expense of
flexibility. I did not went that way, but maybe that's a question the
current developpers will want to reconsider?

Anyway, is there interest in doing such a thing? Given that there were
already some attempts with another build system (qmake) and that using
the recursive capabilities of the autotools is not without impact, I am
sending this mail to see if I should pursue my attempts in order to show
something more polished (adequate for inclusion in the SVN tree).
Do not hesitate to encourage or refrain me to do that - this is why I
ask.

Thank you for your attention.

Rodolphe


[1] Unfortunately, I wiped out the entire MO-2007 source while I
(thinking I was) cleaning the separate build tree. Modulo the
frustration, I will probably redo it soon as it involved more tuning
than heavy work; but you'll have to wait a little more if you want to
see a patch for the fine details.
[2] Personnally, I think this should be done anyway, it's the way the
autotools have been designed (whether you like it or not).