From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30667 invoked by alias); 8 Dec 2002 10:48:56 -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 30631 invoked from network); 8 Dec 2002 10:48:51 -0000 Received: from unknown (HELO mx09.cluster1.charter.net) (209.225.8.19) by sources.redhat.com with SMTP; 8 Dec 2002 10:48:51 -0000 Received: from [66.189.46.2] (HELO platinum.local.) by mx09.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 37821263; Sun, 08 Dec 2002 05:48:50 -0500 Date: Sun, 08 Dec 2002 02:48:00 -0000 Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: zack@codesourcery.com, neroden@twcny.rr.com, gdb-patches@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com, gcc@gcc.gnu.org To: Alan Modra From: Klee Dienes In-Reply-To: <20021205231909.GY27956@bubble.sa.bigpond.net.au> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00415.txt.bz2 On Thursday, December 5, 2002, at 06:19 PM, Alan Modra wrote: > On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote: >> Perhaps --enable-maintainer-mode could be extended to specify a PATH >> to use to find the tools. > > It would need to be on a per-directory basis. Something like > > --enable-maintainer-mode=\ > "gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes" What if the rules generated by --enable-maintainer-mode were to pass a version number to each of the tools when using them to re-generate files? The version number passed would be the same version number used to generate the existing version of the generated files. Then the autotools could either dispatch to the correct version of the tool based on the version number, or perhaps generate an error if the version numbers did not match. In order to upgrade the generated files in a directory to a newer version, the user would have to explicitly run autoreconf or run he appropriate autotools directly. This would make it a lot harder for a maintainer to accidentally use the wrong version of an autotool when regenerating files in a directory. It would also make it possible to write a top-level script that would explicitly re-generate all of the files in a tree with explicitly specified versions (or at least verify that the versions being used were correct). Regardless of how we choose to do it, though, I think it's important that maintainers be able to update individual subdirectories to newer versions of the autotools independently of each other (even if the way we choose to do that is to say "don't run global --enable-maintainer-mode, and be aware of the versions of the autotools you are using"). If we don't, the bar for updating versions of autotools is just too high. Trying to coordinate a simultaneous upgrade of even a simple change across the combined src+gcc repository is a huge amount of work --- if that's the only way to do upgrades, it seems much more likely that the upgrades will tend to not get done. The thought of even *touching* sid is daunting to me, much less the thought of trying to claim that I've changed all of its Makefiles and understand the changes.