Autoconf people, it would be very helpful if autoconf instituted versioning support, i.e. a way for build scripts and the like to specify which version of autoconf to use. ...
I'm not sure I understand why this is such an issue.
When building from source, one rarely changes needs to make patches to configure.{in,ac} and then run autotools*. And I have a tool that builds my entire linux system from scratch, and I pretty much live bleeding edge on EVERYTHING.
You don't cross-compile for embedded CPUs, I bet :-) That's what makes me need to muck with autoconf stuff so much; many packages need patches to make them cross-compile-friendly.
If you're building packages for distribution, you pretty much MUST use a chroot environment anyway to be sure you're using known versions of libc, binutils, gcc, rather than whatever may be installed on the system. Apply the same to autoconf.
Sure, I could, and maybe I will. But all I need is access to a recent autoconf side by side with the old autoconf-2.13. All the distros make autoconf available as /usr/bin/autoconf, but the name they use for autoconf-2.13 varies:
Red Hat 8.x: /usr/bin/autoconf-2.13 Debian: /usr/bin/autoconf2.13 Mandrake: /usr/bin/autoconf-2.13 Cygwin: /usr/autotool/stable/bin/autoconf
How painful would it be for the autoconf maintainers to declare the following?
-----------------------------------------------------------
Linux distributors are encouraged to make autoconf-2.13
available as the executable
/usr/bin/autoconf-2.13
-----------------------------------------------------------That's all it would take to make things easy for people like me.
Myself, I'll just make that symlink myself while I'm waiting for Debian and Cygwin to wise up. - Dan
