Brian and I chatted about this in person -- he doesn't have too strong of an opinion here.
We checked versions shipped in RHEL: RHEL4: AC 2.59, AM 1.9.2, LT 1.5.6 RHEL5: AC 2.59, AM 1.9.2, LT 1.5.22 Meaning: they're both really ancient. I personally don't mind forcing developers to have more modern versions because we're a fairly small group of people (vs. users). Does anyone else have an opinion here? On Feb 25, 2010, at 1:55 PM, Barrett, Brian W wrote: > 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 > > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
