On 03/02/2012 07:15 AM, Stefano Lattarini wrote: > Also, note that the workaround removed in c3797b86ccbd9 was severely > broken to begin with (that is explained in the commit message); > re-introducing it only to make autoconf buildable out-of-the box on > an obsolescent Solaris box seems a very bad idea. > > On the top of all that: Automake is a maintainer tool, so it's OK for > it to have requirements tighter w.r.t. older tools that the ones in > place for its generated Makefiles. After all, Autoconf is already > requiring a fairly modern GNU m4, so why not require perl 5.6 as well? > > In conclusion, I'm quite oriented to close this bug report as a > "wontfix".
That's fair for automake. Paul, would it be okay if for autoconf we borrow the same configure check as automake is using, and globally bump the requirement to be consistent across the autotools? Technically, you can use autoconf without automake, so automake requiring newer than autoconf is possible; but since the tools are generally used together, being consistent up front can't hurt. Stefano, is it worth factoring the automake perl version check into a separate .m4 file that can then be shared across automake and autoconf, in the same manner that Getopt.pm is shared? -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
