Re: please bring back program suffix for autoconf bin files

[Mike Castle]

In article <address@hidden>, Dan Kegel  <address@hidden> wrote:
>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.  Normal developers won't need it, perhaps, but
>people like me who are trying to write a script to
>build fifty different open source packages from source
>would find it *very handy*.
>
>As you may know, Debian and Cygwin have both found this
>important enough to come up with their own way of doing
>it, but having different schemes for Debian, Cygwin, and
>the various Red Hats makes life difficult.  A unified
>versioning scheme from the autoconf maintainers would help.
>It doesn't even need an autodetecting script; the
>"/usr/bin/autoconf is a symlink to the newest version" scheme
>would be fine.

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.

Manage the changes to the input file to work on your system, run the tools,
and publish the diff to the resulting configure to your build system.

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.

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc