From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9568 invoked by alias); 5 Dec 2002 21:31:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9538 invoked from network); 5 Dec 2002 21:31:56 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 5 Dec 2002 21:31:56 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 18K3b6-0005zu-00; Thu, 05 Dec 2002 13:31:52 -0800 To: Nathanael Nerode Cc: klee@apple.com, gdb-patches@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. References: <20021205190728.GA11507@doctormoo> From: Zack Weinberg Date: Thu, 05 Dec 2002 13:31:00 -0000 In-Reply-To: <20021205190728.GA11507@doctormoo> (Nathanael Nerode's message of "Thu, 5 Dec 2002 14:07:28 -0500") Message-ID: <87hedsi247.fsf@egil.codesourcery.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00186.txt.bz2 Nathanael Nerode writes: > Accordingly, I suggest getting clean patches for small sets of > directories, making sure they work, getting them reviewed, and then > putting them in; and then starting on the next set. Keep sending update > notices to the various lists regarding which directories use the 'new' > tools and which use the 'old'. If you can make scripts which work > correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means > do so *first*, and mark those scripts as "compatibile with both", of > course; but I expect that will only happen for the simplest directories. I'd like to remind everyone involved that last I checked it was flat impossible to do what libstdc++-v3/configure.in needs to do, using autoconf 2.5x. I am not particularly sanguine about the situation having changed, since it involved the undocumented AC_NO_EXECUTABLES macro that as far as I know nobody but us has a use for -- and we're not using it, because it doesn't do what we need it to do. Until that is resolved, which will involve submitting patches to autoconf, getting them accepted upstream, and waiting for a release, gcc *cannot* move to autoconf 2.5x. We are not being stick-in-the-muds because we want to. (Please, I beg of you, prove me wrong about this problem.) I am concerned about the prospect of having the src repository update to 2.5x while the gcc repository is still stuck with 2.13. Having different parts of the combined tree need different versions of autotools is a recipe for disaster. But I do see a way forward. It goes like this. One directory at a time, we go through and do whatever it takes to get that directory's configure.in to work properly with both 2.13 and 2.5x, independent of what version of autoconf was used to generate configure in other directories. This may involve submitting patches to the autoconf maintainers. Whoever volunteers to do this must be willing to maintain these scripts in that state indefinitely -- I did it for the gcc subdirectory a year or so ago and I discovered a couple weeks back that it had mysteriously broken. Once the entire tree makes it into this state, we have a flag day where we bump AC_PREREQ and regenerate everything. And only then can we start using 2.5x specific features in configure scripts. As for libtool and automake, my suggestion is, as usual, that both should be eradicated from the face of the Earth; as this proposal is probably a non-starter, I decline to discuss what to do with them any further. zw