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: <3BCB0C10.6060409@ece.gatech.edu>
Date: Mon, 15 Oct 2001 12:17:20 -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: Corinna Vinschen <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> <3BC94CE5 DOT 8070206 AT ece DOT gatech DOT edu> <20011015111857 DOT I1696 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:

> On Sun, Oct 14, 2001 at 04:29:25AM -0400, Charles Wilson wrote:
> 
>>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.
>>
> 
> Pooah.  I'm not quite sure if I want to have that extra work.  I'm
> maintaining autoconf and automake only since nobody else is doing
> that.  If you can convince me that it's no extra work or that you're
> always available if something not ok with the script, though...


I'm not going to lie to you -- it IS extra work.  However, I hope that 
the extra work is *minimal* -- and to convince you that it is necessary.

The "stable" branch:
   autoconf-2.13
   automake-1.4p5
I would assume that these will never need to be updated.  All current 
development by the GNU guys is on the 2.52/1.5 branches.

the "devel" branch:
   autoconf-2.52
   automake-1.5
These are the versions you are already maintaining, and keeping current. 
  No *additional* work involved here.

the scripts:
   Since these are brand new, it would be naive to suppose that they 
were perfect.  However, they are feature-complete.  the only changes 
that would be required are (a) bugfixes and (b) update the 
option-parsing to track changes in newer auto*devel releases.  Both 
sorts of changes are minimally intrusive, and easy -- it's only shell 
script, after all.  And have I ever abandoned a contribution of mine in 
the past?

So: the *extra* work is minimal -- basically, only bugfixes to the 
scripts; and I'll be around.

Necessity:
   We *must* have both vesions (of autoconf, at least) available -- and 
not just for my grand libtool plan.  We are entering a "phase" were some 
packages will AC_PREREQ(2.50) -- but others will delay the transition, 
and will remain AC_PREREQ(2.13) (or earlier).  Since 2.5x is NOT 
completely backward compatible with 2.13, we are left with three choices:
   a) provide both 2.13 and 2.52
   b) immediately fork every package we distribute, fix 'em so that they 
all work with 2.5x -- AND then convince their upstream maintainers to 
accept these changes.
   c) do NOT support 2.5x at all; stay with 2.13
   d) okay, developers: you can't work with the autostuff of packages 
that require the OTHER autoconf.  Sorry.  (Okay, you could use setup to 
uninstall/reinstall and switch between the two versions).  Or developer1 
can promise to stay at 2.13 -- and he can be in charge of newlib's 
auto-stuff, and developer2 can track 2.5x -- and she can be in charge of 
libiberty's auto-stuff...

cgf has already ruled out (b).  In (c), it probably will work NOW with 
most packages -- but we're left behind when the upstream maintainers 
eventually DO update and AC_PREREQ(2.50).  (d) is just plain silly.

So: the additional effort is minimal (since I already wrote the scripts 
and did a lot of testing), and I'll be around, and SOMETHING along these 
lines is necessary -- (a) is the only real choice we have.

--Chuck