Re: please bring back program suffix for autoconf bin files

[Charles Wilson]

Mike Castle wrote:
> 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.

Sure -- but you're running linux; not everybody does.  On cygwin and 
mingw, if we want to use bleeding-edge libtool's support for building 
shared libs (DLLs), we have to use automake-1.7.x and autoconf-2.5x. 
so, we have to have those versions installed.

OTOH, there are some packages that are a bit, err, tricky to reautoconf 
with the latest autoconf version. Say, binutils, gcc, and cygwin itself, 
for instance.  [Granted, work is ongoing to remedy that problem, but 
right *now* you can't use ac-2.5x with cygwin/winsup, or binutils, or gcc].

Now, cygwin/winsup has files added and removed all the time, and changes 
are made to its configure.in regularly.  Which means we have to have 
ac-2.13 installed.

Oops.

We've more-or-less solved this issue on cygwin; it's ugly and hackish, 
uses wrapper scripts and non-standard install locations and weird 
patches to automake (see the 'dirlist' patch that went into official 
am-1.6.2).  And it's a PITA for me to maintain (yes, I'm the actual 
official maintainer for the cygwin autotool wrapper scripts, as well as 
both of our versions of the autotools).   I wouldn't wish those hackish 
wrappers on anyone else - and I can't WAIT for the day I can trash the 
whole mess.

So I strongly support peaceable coexistence between autoconf versions, 
as a means of future-proofing.  this won't help the current logjam, 
unless the "coexistance" patch -- whatever it is -- is backported and an 
autoconf-2.14 is released(*); but it will help in the future, if there 
is another backwards-incompatible change in autoconf that artificially 
divides the free software ecology into two uncooperative 
halves...ac-2.5x vs. ac-3.x?

(*) I don't recommend or advocate that; it's far too late for the 2.13 
vs 2.5x transition.  But, in the future, 2.5x vs 3.x, sure!

Making it easy for people to have BOTH the old autoconf (e.g. 2.5x) and 
the new autoconf (e.g. 3.x) installed on *the same system* will actually 
*speed* adoption of the new tool; the current irretrievable situation 
w.r.t. 2.13 and 2.5x has, IMO, slowed migration because of (reverse) 
network effects: Joe developer can't switch his system over to 2.5x 
until most of the projects he hacks have already made the switch; but 
project X can't "flag day" over to 2.5x until most of its developers 
have updated their systems.  Result: 18 months since 2.50 was released, 
and gcc -- GCC!!! -- is just now beginning to switch over...

> 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.

Errmmm...chroot?  What's chroot? :-)  That's something that works on 
linux and other real unixes, but cygwin and mingw/MYS don't have that.

--Chuck