Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3BC94CE5.8070206@ece.gatech.edu>
Date: Sun, 14 Oct 2001 04:29:25 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: Autotools; new versions
References: <3BAA33FD DOT 9C1B704C AT ece DOT gatech DOT edu> <20010920143410 DOT B5666 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> 
> Robert suggested that debian has a wrapper that tries to infer which
> version of autoconf to run.  
> 
> Is this something worth considering?

Take a look here:
http://www.neuro.gatech.edu/users/cwilson/cygutils/autotools/

I've put up a "sourceware"-style tree with both versions of autoconf, 
both versions of automake, and wrapper scripts.  (There's also a 
setup.ini).  So, you can download this whole tree, and run setup.exe on 
the local directory and "play" with this set of packages.

It seems to work okay given my testing, but a wider test would be a good 
idea -- and feedback on the wrapper scripts themselves...

I incorporated Earnie's suggestion of using AUTO_DEVEL and AUTO_STABLE 
environment variables to override the default /usr/auto-devel/ and 
/usr/auto-stable/ paths.

Why did I do this?  Because we have a need for both "old" versions of 
autotools and the cutting edge versions to coexist.  We need the old 
versions in order to work with existing packages that have not yet taken 
the plunge and converted to the newer versions.  But, we need the newer 
versions because the super-special dll-supporting libtools don't work 
with the older autotools.

And I want the new super-special dll-supporting libtool.

--Chuck

P.S. corinna: I don't really want to take over maintainership of the 
autoconf/automake packages, but I am making this contributition if you 
(and the rest of the list) think it is useful.