[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please bring back program suffix for autoconf bin files

From: Charles Wilson
Subject: Re: please bring back program suffix for autoconf bin files
Date: Sat, 01 Mar 2003 00:00:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

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

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 regularly. Which means we have to have ac-2.13 installed.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]