From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2016 invoked from network); 4 Jun 2001 08:56:49 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Jun 2001 08:56:49 -0000 Received: (qmail 26080 invoked by alias); 4 Jun 2001 08:56:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14704 Received: (qmail 26053 invoked from network); 4 Jun 2001 08:56:34 -0000 From: "Bart Schaefer" Message-Id: <1010604085515.ZM31183@candle.brasslantern.com> Date: Mon, 4 Jun 2001 08:55:15 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH: Re: zsh and autoconf-2.50" (Jun 4, 8:36am) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: PATCH: Re: zsh and autoconf-2.50 Cc: zsh-workers@sunsite.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 4, 8:36am, Zefram wrote: } } Cute technique. But previously we have never attempted to maintain } compatibility with more than one version of autoconf; we have always had } a flag day where all developers have had to switch to the new version, and } it has never been a problem. Previously, however, we were not maintaining the source code in CVS, and the developers therefore always had the configure script and did not need to run autoconf. Since SourceForge, it's quite likely that a developer might get the source code without getting the configure script. This means that even "casual" developers would be forced to upgrade to the latest autoconf. Putting the configure script into CVS too is certainly an option, but it is somewhat error-prone -- it's too easy to commit one without the other, and eventually we start running into issues with autoconf 2.5x vs. 2.5y, e.g. both autoconfs work with configure.ac but produce slightly different configure scripts so that spurious diffs can get committed. } When dealing with packages as convoluted as ours, such as to require } a specific version of autoconf, it does not seem too much of a burden } for developers (specifically, developers that modify the configure } source) to marshall more than one version of autoconf. My specific objections are that (a) as already noted, it's not limited just to developers who modify the configure source, and (b) when dealing with package-manager-based installations such as most linux distributions, it's somewhat more difficult to "marshall more than one version" without causing unintended side-effects. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net