[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] cluster master trees moving to autoconf/automake/libtools

On Fri, 2009-05-29 at 15:55 +0200, Fabio M. Di Nitto wrote:
> Hi all,
> the new development trees have started moving towards a more standard
> build system than the one we have in place now.

A very fair question has been raised on IRC:

"Why are we moving to autotools?"

I clearly failed to communicate that in my first email and I believe it
deserves a proper explanation.

Historically I have been maintaining and took responsibility for the
whole build system in cluster.git, even before STABLE2 was branched a
couple of years ago. For a long time the system has been used for
STABLE2/STABLE3/master trees. Maintaining a custom build system was
fairly simple as the amount of branches was minimal and cherry picking
across was "quick".

With the recent split of the master tree into 8 projects, it means
maintaining at least 10 custom build systems with slightly different
requirements and make snippets. This clearly doesn't scale properly in
the long run when branches in master trees will start to appear.
A bug fix or any change would have to be propagated N times.

autotools replace in full our make/ directory (that contains all custom
make file snippets), making all the scripting common to all our projects
and common to many others projects. The quality of the make snippets
provided by autotools is far superior compared to the ones I will
probably ever be able to write, removing tons of limitations in our
current environment and Makefile.am are a lot smaller than some of the
Makefiles we are carrying around.

As a team, we are somewhat new to autotools. There is no secret about
it. The first project to transition from custom to autotools was
corosync and the transition was painful. I can't possibly agree more on
that front as I spent weeks cleaning it up (and several hours with a
shrink to get rid of AC_NIGHTMARES() ;)).

On the bright side, now we have a much stronger knowledge of autotools.
It took less than 3 days to convert cluster.git master branch with only
few minor bumps in the process (git log can show).

There is no new procedure for developers to use autotools, as it is the
same as corosync/openais, so no new learning curve and no new tools to

>From a developer/maintainer perspective, I see the removal of custom
build system as a benefit. The only price I had to pay was to install
libtool 2.2.x, but Jim's script took care of that for me (the same
script people have used for corosync/openais + little update).
As a final result of cluster.git transition is a build system that's
approx ~1000 lines less of Makefile stuff vs the original > 2000 lines.

The reason why we are using libtools is to guarantee that our code will
be linked properly. This has been a nightmare to get right even in our
simple custom build system and there is still space for errors. A chance
that I believe we don't want to take for our projects. As an example you
might notice how libraries in cluster.git master are properly linked vs
STABLE3. Those changes are showing some of the weaknesses of a custom
build system (and yes we will get STABLE3 fixed of course).
A lot of horror stories are floating around libtool. I have been testing
version 2.2 deeply for a while now and it didn't show any of those
problems that people have been reporting me (speed, relink at install
time and so on) and that's also why we are requiring such a high

>From a user/distro perspective, I see that as a benefit in at least 2
areas. The distro maintainer doesn't have to learn yet another custom
build system and we don't require perl to build anymore.

As an overall stack, corosync+openais+cluster, we will offer a
consistent build system across the whole set of trees. People will be
able to, in 99.9% of the cases, use the ./configure invocation for all
projects and get a stack built and running.

I'll spare you the usual arguments for "yes autotools!" "no
autotools!".. :) I am sure a quick google search can find all the
flamewars in history about this topic you might ever want to read ;)

I hope this explain the motivations for moving forward. I welcome any
question of course.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]