From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32320 invoked by alias); 25 Dec 2002 02:47:51 -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 32287 invoked from network); 25 Dec 2002 02:47:50 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 25 Dec 2002 02:47:50 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBP2l6Y14262; Tue, 24 Dec 2002 21:47:06 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6) with ESMTP id gBP2l5aH001141; Wed, 25 Dec 2002 00:47:05 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id gBP2l4jJ001137; Wed, 25 Dec 2002 00:47:04 -0200 To: Nathanael Nerode Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com Subject: Re: Planning for the Autoconf 2.5x transition? References: <20021224055606.GA957@doctormoo> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Thu, 26 Dec 2002 05:47:00 -0000 In-Reply-To: <20021224055606.GA957@doctormoo> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg01422.txt.bz2 On Dec 24, 2002, Nathanael Nerode wrote: > 1. Make all directories have configure.in scripts which work correctly > with *both* 2.13 and 2.5x, then switch over. This was my plan, back when I thought I'd ever have time to put into this effort. > 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. You can write m4 conditionals on the autoconf version and have code for 2.13 and for 2.5x, where it is actually needed. In most cases, all you should need is to fix m4 quoting errors that autoconf 2.13 didn't care about but that autoconf 2.5x happens to trip over. > 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. This is possible, but it takes some additional effort because of caching issues. The one that comes to mind is that some early 2.5x versions of autoconf changed the cache value of AC_EXEEXT in the no-extension case in a way that autoconf 2.13 would think the extension was .no. If any sub-package happens to use a configure script generated by such versions of autoconf, any subsequent configure runs of scripts generated by autoconf 2.13 would be in trouble. I'm not sure this was actually `fixed' in newer versions of autoconf 2.5x. > 3. Create autoconf-2.5x branches in src and gcc. I don't think this is a good idea. It's unlikely we'll ever get testing coverage for these changes before the branches are merged into mainline. The only advantage of a branch is that one could then take his/her (your? :-) time to implement any needed changes and, by then, some of them might have become obsolete. Using conditional code in configure scripts that actually require changes that are not bug-fixes for latent bugs seems far superior to me. > The next question is: what are the actual, known problems with changing to > autoconf 2.5x? Quoting problems were the most common problem found by early adopters of autoconf 2.5x. The good news is that, when I first started playing with the idea of converting the uberbaum tree to autoconf 2.5x, there weren't any. The second most common problem for multi-configure packages is (was?) the AC_EXEEXT issue. The fix is as simple and mechanical as overriding the cache value such that it is autoconf-2.13 compatible (empty) whenever it is found to be `no' just before updating the cache file. We could even override the AC_EXEEXT macro to that effect. AC_NO_EXECUTABLES as of the latest version of autoconf is unfortunately useless for gcc's target libraries. I don't know whether anything came out of the last time this was discussed in the autoconf CVS tree. It's easy enough to override it with our own version, using m4 conditionals. We can even use a back-port of the feature for autoconf 2.13. The one other issue that got me more worried as that a number of configure.in scripts that (implicitly) ran a pair of AC_ macros that both wanted to be the first to do compile (or preprocessor?) tests, and they'd complain loudly at configure-generation (autoconf) time and abort if they found that other tests had already been processed (even the tests performed by the other such macro). If there are two macros like that, there's no ordering that could satisfy both, so this is a bit of a problem. I remember one of the macros was AC_ISC_POSIX, but I don't remember the other. I've no idea whether the problem is still present in the current version of autoconf; you should know as soon as you run into the problem. IIRC, this problem affects packages that use CY_GNU_GETTEXT, that AC_REQUIREs AC_ISC_POSIX. > 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... m4_include is just a different way to spell m4's include/sinclude, so that's not a good reason to switch to autoconf 2.5x. Have a look at bfd/acinclude.m4 for sample uses of sinclude. Heck, even gcc/aclocal.m4 uses this trick these days :-) And I see gcc/aclocal.m4 contains an AC_ISC_POSIX that works around the problem I mentioned above. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer