I'm assuming: libtool: 1.5.26 autoconf: 2.61
On Nov 12, 2013, at 4:00 PM, Jim Jagielski <j...@jagunet.com> wrote: > So what versions of autoconf and libtool should we > be baselining for 2.2.x? > > On Nov 12, 2013, at 3:33 PM, Jeff Trawick <traw...@gmail.com> wrote: > >> On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >> On Nov 12, 2013, at 2:39 PM, Ben Reser <b...@reser.org> wrote: >> >>> On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote: >>>> Oh yeah... I recall you had an issue with me building >>>> because of potential issues with using a later, but >>>> still 100% valid autoconf/libtool setup. I am not >>>> going to downgrade just to build 2.2 so if that is >>>> *really* a concern, backed-up by the PMC, then someone >>>> else will need to RM. >>> >>> You don't need to downgrade at all. Just build autoconf/libtool >>> versions and install them in another dir. Add that to the front of >>> your path and off you go. >> >> Ugg. :) >> >> My reason to not downgrade isn't because of having >> different versions but because ALL my testing and building >> on my various machine is with the newer set. So all my >> confidence on my voting is based on that toolset. Down- >> grading throws an unknown factor into my process which >> reduces my "trust" which was based on using a different >> toolset. >> >> My 2 cents: Developers test the build on a wide variety of autotools anyway. >> Looking at all the differences from one release tarball to the next is >> useful, but if autotools versions are jumping around then the bits generated >> from .m4/.in changes are somewhere inside an unreviewable mess. If users >> didn't report an autotools-based problem before, they presumably won't now >> if the same versions are used. (But 2 cents doesn't buy much, and I don't >> want to add any heat here.) >> >> -- >> Born in Roswell... married an alien... >> http://emptyhammock.com/ >
