I think our last set of minimums was based on being able to use RHEL4 out of the box. Updating to whatever ships with RHEL5 probably makes sense, but I think that still leaves you at a LT 1.5.x release. Being higher than that requires new Autotools, which seems like asking for trouble.
Brian On Feb 25, 2010, at 4:47 PM, Jeff Squyres wrote: > 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/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
