From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7004 invoked by alias); 25 Nov 2004 21:28:41 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 6507 invoked from network); 25 Nov 2004 21:28:22 -0000 Received: from unknown (HELO mail2.codesourcery.com) (66.160.135.55) by sourceware.org with SMTP; 25 Nov 2004 21:28:22 -0000 Received: (qmail 26032 invoked from network); 25 Nov 2004 21:28:22 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by mail2.codesourcery.com with SMTP; 25 Nov 2004 21:28:22 -0000 Received: (qmail 12953 invoked from network); 25 Nov 2004 21:28:21 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 25 Nov 2004 21:28:21 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CXRA3-0000jh-Mh; Thu, 25 Nov 2004 21:28:19 +0000 Date: Thu, 25 Nov 2004 21:28:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Zack Weinberg 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) In-Reply-To: <87hdndmyg8.fsf@codesourcery.com> Message-ID: References: <87is7tejx4.fsf@redhat.com> <87hdndmyg8.fsf@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00346.txt.bz2 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. 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. > 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. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)