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: <3BAA33FD.9C1B704C@ece.gatech.edu>
Date: Thu, 20 Sep 2001 14:22:53 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Autotools; new versions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Since there are incompatibilities between
  autoconf-2.13 and autoconf-2.5x
  automake-1.4  and automake-1.5

and most (cygwin-external) projects have been slow and/or resistant to
migrate to the newer versions,

and cgf doesn't want to "push the envelope" on autotools from cygwin
(let other projects migrate FIRST, then we follow)

and libtool/autoconf/automake must all share the same prefix (usr or
usr/local or...)

and the newest version (not even in CVS yet) of libtool that
transparently supports dll-building on cygwin requires the NEW versions
of autoconf/automake

I propose:

Two versions of automake and autoconf:
  automake
     based on 1.4p2 (the newest 'pre-1.5-changes' version)
     installed into /usr
  autoconf-2.13
     installed into /usr
  automake-devel
     based on 1.5
     installed into /usr/autotools/
  autoconf-devel
     based on 2.5x
     installed into /usr/autotools/
That way, "normal" maintainance and development can continue without any
environment changes -- e.g. we can still play with the gcc guys, and the
binutils guys, etc.  However, those who want to use the newer tools can
do so by putting /usr/autotools/ in the front of their path.  This also
provides a nice location for an upcoming libtool package.

Eventually, the -devel versions can be moved over the the main /usr tree
-- after the other projects (gcc, binutils, etc) have led the way into
the new territory.

However, this requires Corinna, the current maintainer of autoconf/make,
to do extra work -- so she's got a de facto veto over this proposal. 
Notwithstanding the fact that Corinna can just say "I don't want to do
that", does anybody have any opinions for/against this proposal?  

Corinna -- do you want^W^W^W are you willing to do this, if folks think
it's a good idea?

--Chuck