Mail Archives: cygwin-developers/2001/08/15/18:09:25

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <>
Date: Wed, 15 Aug 2001 18:08:26 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: CD List <Cygwin-Developers AT Cygwin DOT Com>
Subject: Re: Does CVS build?
References: <20010815132450 DOT A1468 AT dothill DOT com> <3B7AEC05 DOT 7FBF0C8C AT yahoo DOT com> <20010815155157 DOT B20199 AT redhat DOT com> <20010815162916 DOT A28118 AT redhat DOT com> <20010815171031 DOT A29030 AT redhat DOT com> <3B7B0796 DOT 2DF865D1 AT yahoo DOT com> <3B7AED5F DOT 7050603 AT ece DOT gatech DOT edu> <3B7B0B65 DOT 968A332A AT yahoo DOT com>

Earnie Boyd wrote:

> Charles Wilson wrote:
>>Which autoconf were you using to regenerate configure?
> I used 2.13.  

Good.  If I can come up with some compatibility patches that make it 
"work" for 2.52, then at least there's *somebody* around who can make 
sure I don't break things for 2.13.

> I know better than to get rid of a good thing just yet. 
> There are so many changes happening with autotools that updating
> versions just has to be a HOALOW.  Just keeping the correct versions of
> sister tools is enough to throw you into a nightmare.

Yes, but...the autoconf people no longer support 2.13.  In fact, the 
situation is remarkable similar to B20.1 vs. 1.x.x:

Q) but X worked on 2.13
A) 2.52 provides many additional features and is the future path.
Q) but there's so much stuff that's incompatible with the new version
A) Not if this "stuff" followed the rules originally.  Most of the 
problems are cause when people redefine internal macros (like 
AC_PROG_CC_WORKS) in external projects.  Of course we reserve the right 
to modify internal architecture.  Other than those problems, there are 
very few incompatibilities -- and we even provide a tool to do the 
migration for those (autoupdate).  Unfortunately, autoupdate can't fix 
problems that arise when packages break the rules (.._WORKS & friends)


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019