From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10925 invoked by alias); 24 Dec 2002 05:57:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10916 invoked from network); 24 Dec 2002 05:57:30 -0000 Received: from unknown (HELO mailout5-0.nyroc.rr.com) (24.92.226.122) by 209.249.29.67 with SMTP; 24 Dec 2002 05:57:30 -0000 Received: from doctormoo (syr-24-24-16-193.twcny.rr.com [24.24.16.193]) by mailout5-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gBO5vHF14999; Tue, 24 Dec 2002 00:57:18 -0500 (EST) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 18Qi2w-0000Fd-00; Tue, 24 Dec 2002 00:56:06 -0500 Date: Tue, 24 Dec 2002 06:11:00 -0000 To: gcc@gcc.gnu.org Cc: gdb@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com Subject: Planning for the Autoconf 2.5x transition? Message-ID: <20021224055606.GA957@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-12/txt/msg01399.txt.bz2 OK, this subject has come up before, but I think it's time to bring it up again. Autoconf 2.5x would be a significant improvement to the configure machinery. It's not an entirely compatible transition. But we have to do it, and I'd prefer sooner rather than later. There are several questions to be resolved here. I see three primary schemes which could be used for this: 1. Make all directories have configure.in scripts which work correctly with *both* 2.13 and 2.5x, then switch over. The major problem with this is that I think it's probably impossible. At least some directories will need to have different code for the two versions. 2. Transition one subdirectory at a time. The major problem with this is that for quite a while, two versions of autoconf would be needed to rebuild the whole tree. 3. Create autoconf-2.5x branches in src and gcc. The major problems with this are the need to port any configury changes up from the trunk, the general nasty slowness of CVS branches, and the future difficulty of getting the branch merge approved by all projects at once. -- I'm happy to attempt to coordinate whichever scheme is considered best. I just think that this should actually be started, so that it will be finished sometime in the next three months or so. The next question is: what are the actual, known problems with changing to autoconf 2.5x? The libstdc++-v3 maintainers have noted the particular problems they have; I haven't heard comments about particular problems with any other subdirectories. -- The reason I'm harping on this is that a number of my other little configury projects would be a lot happier with an autoconf which provided m4_include. Large change for that one benefit, I know... --Nathanael