From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22219 invoked by alias); 26 Nov 2004 21:48:27 -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 21818 invoked from network); 26 Nov 2004 21:48:14 -0000 Received: from unknown (HELO mail2.codesourcery.com) (66.160.135.55) by sourceware.org with SMTP; 26 Nov 2004 21:48:14 -0000 Received: (qmail 30708 invoked from network); 26 Nov 2004 21:48:13 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by mail2.codesourcery.com with SMTP; 26 Nov 2004 21:48:13 -0000 Received: (qmail 15470 invoked from network); 26 Nov 2004 21:48:12 -0000 Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 26 Nov 2004 21:48:12 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Fri, 26 Nov 2004 13:48:12 -0800 To: "Joseph S. Myers" Cc: Richard Sandiford , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305) References: <87is7tejx4.fsf@redhat.com> <87hdndmyg8.fsf@codesourcery.com> From: Zack Weinberg Date: Fri, 26 Nov 2004 21:48:00 -0000 In-Reply-To: (Joseph S. Myers's message of "Thu, 25 Nov 2004 21:28:19 +0000 (UTC)") Message-ID: <878y8omgdf.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00477.txt.bz2 "Joseph S. Myers" writes: > On Thu, 25 Nov 2004, Zack Weinberg wrote: > >> I think this is a fine idea (though I cannot approve it) and I would >> like to encourage you also to break the version number proper and the >> date stamp out of gcc/version.c. If we could have two syntax-free >> files somewhere (suggest config/gcc-version, config/gcc-datestamp) >> that were parsed by everything that cares, then we could eliminate all >> the remaining copies of those numbers, and people maintaining modified >> versions of GCC wouldn't have merge conflicts in version.c every time >> they updated from the official sources. Oh, and it would be one fewer >> reason for gcc/Makefile to rebuild everything after a cvs update. > > Note that doing this will involve changing update-web-docs, as the > version number will then be in a generated .texi file included from > gcc-common.texi; updating branching.html and releasing.html > (remembering that releasing.html may be referred to by the RMs for > older active branches as well, so needs to cover both cases); and > updating gcc_release. And the cron job that bumps version.c. > It would be possible to have a third file gcc-status containing > "release", "prerelease" or "experimental" to determine the type of > version and whether the datestamp goes in the version number, which > would then change "prerelease" -> "release" in the release process > and be parsed to determine the setting of DEVELOPMENT presently in > gcc-common.texi, and a fourth file gcc-type that contains "FSF" for > FSF mainline and release branches, or some other string for other > branches and local modifications. I'm undecided on whether this would help all that much. I don't want a proliferation of weird little files in the top level config/. >> By syntax-free I mean that these files should contain the literal text >> 3.4.2 and 20041124 (respectively, for example) and nothing else, so >> that using them is as simple as > > I'd suggest the inclusion of a trailing newline after the version > number/date. Um, yeah. zw