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

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

[Fabio M. Di Nitto]

Hi all,

the new development trees have started moving towards a more standard
build system than the one we have in place now.

So far only cluster.git master branch has been converted to
autoconf/automake/libtools. The others will follow shortly.

Normal users don't have to worry about those tools, only developers that
need to bootstrap the trees do.

The script in attachment, kindly provided by Jim Meyering, will help to
build the correct versions of the tools. This script is the same as the
one that is used for corosync/openais autotools bootstrap process.
The only difference is that it builds libtools (2.2.7a) and more recent
version of automake.

Most if not all distributions have sufficiently recent tools except for
libtools. You can opt to build only what you really need by hacking the
top level section of the script.

Those tools can be used to build corosync/openais too. So there is no
problem whatsoever in that respect.

Just a few notes in the overall process:

- the bootstrap process is the same as corosync/openais.
- the variables for paths are the same (same sanity checks and
settings).
- in 99.9% of the case I believe you can use the same ./configure
invokation and you will achieve the expected results.
- not all config options from the old build system have been ported yet
as some of them makes none to little sense to me. If you feel that one
or more should be re-added please just let me know.

The conversion is "fresh" expect a few bugs. Keep in mind it's master :)

Let me know if it works/doesn't work so I can actually fix stuff around.

Fabio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_auto
Type: application/x-shellscript
Size: 5539 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20090529/98d17aa3/attachment.bin>

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

[Fabio M. Di Nitto]

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
learn.

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
version.

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.

Cheers
Fabio