WHAT: Bump minimum required versions of GNU autotools up to modern versions. I
suggest the following, but could be talked down a version or two:
Autoconf: 2.65
Automake: 1.11.1
Libtool: 2.2.6b
WHY: Stop carrying patches and workarounds for old versions.
WHERE: autogen.sh, make_dist_tarball, various Makefile.am's, configure.ac, *.m4.
WHEN: No real rush. Somewhere in 1.5.x.
TIMEOUT: Friday March 5, 2010
----------------------------------------------------------------
I was debugging a complex Automake timestamp issue yesterday and discovered
that it was caused by the fact that we are patching an old version of
libtool.m4. It took a little while to figure out both the problem and an
acceptable workaround. During this process, I noticed that autogen.sh still
carries patches to fix bugs in some *really* old versions of Libtool (e.g.,
1.5.22). Hence, I am send this RFC to increase the minimum required versions.
Keep in mind:
1. This ONLY affects developers. Those who build from tarballs don't even need
to have the Autotools installed.
2. Autotool patches should always be pushed upstream. We should only maintain
patches for things that have been pushed upstream but have not yet been
released.
3. We already have much more recent Autotools requirements for official
distribution tarballs; see the chart here:
http://www.open-mpi.org/svn/building.php
Specifically: although official tarballs require recent Autotools, we allow
developers to use much older versions. Why are we still carrying around this
old kruft? Does some developer out there have a requirement to use older
Autotools?
If not, this RFC proposes to only allow recent versions of the Autotools to
build Open MPI. I believe there's reasonable m4 these days that can make
autogen/configure/whatever abort early if the versions are not new enough.
This would allow us, at a minimum, to drop some of the libtool patches we're
carrying. There may be some Makefile.am workarounds that are no longer
necessary, too.
There's no real rush on this; if this RFC passes, we can set a concrete, fixed
date some point in the future where we switch over to requiring new versions.
This should give everyone plenty of time to update if you need to, etc.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
