[Linux-ha-dev] heartbeat's build process and configure / autoconf

[Lars Marowsky-Bree]

Hi all,

during this dev cycle I find myself building heartbeat packages pretty
often. Andrew also suggested he does rebuild heartbeat from time to time
;-)

On my not-exactly-slow systems, a package re-build, including a
BasicSanityCheck run, takes just below 7 minutes.

I've stopwatched the rough times of what goes on:

 00:00 - Start of build
+  :10 - Buildsystem setup (ie, copying and untarring sources)
+ 2:00 - automake(!)
+  :05 - autoconf
+ 1:50 - three(!) configure runs
+ 1:25 - make && make install
+  :15 - packaging etc
+ 1:10 - BasicSanityCheck
+  :05 - final buildsystem validation

I find that the largest potential for cutting down the build time is in
the autofoo phases (which combined are roughly half of the whole time
needed; 60-70% if I didn't run BasicSanityCheck as part of the build);
the build itself is pretty fast already (and can be parallelized, so
more hardware can be thrown at it ;-), and BasicSanityCheck just spends
a lot of it's time waiting, so not much to do there.

I'm at a loss at why automake should take so long; this must be possible
to optimize!

The configure runs are somewhat annoying:

The first one is the main one we need. That's fine, and I could live
with that. However, at the end, that one calls configure again inside
libltdl, because apparently that one needs its own configure, which is
pretty sad. HOWEVER, then we progress to the make stage - and the first
thing this does:

+ export 'MAKE=make -j16'
+ MAKE=make -j16
+ make -j16
Making all in libltdl
gmake[1]: Entering directory `/usr/src/packages/BUILD/linux-ha/libltdl'
cd . && /bin/sh /usr/src/packages/BUILD/linux-ha/libltdl/missing --run aclocal-1
.8 
cd . && /bin/sh /usr/src/packages/BUILD/linux-ha/libltdl/missing --run autoconf
 cd . && /bin/sh /usr/src/packages/BUILD/linux-ha/libltdl/missing --run automake
-1.8 --foreign 
/bin/sh ./config.status --recheck
running /bin/sh ./configure ...
...

So, one of those two surely must be superfluous.

Can anyone confirm those rough percentages of time needed? Or even
better, does someone have an idea of how to optimize this? Patches are
being accepted! ;-)



Sincerely,
    Lars Marowsky-Brée <lmb at suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business