This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Richard Sandiford <rsandifo at redhat dot com>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, binutils at sources dot redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Thu, 25 Nov 2004 21:28:19 +0000 (UTC)
- Subject: Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305)
- References: <87is7tejx4.fsf@redhat.com> <87hdndmyg8.fsf@codesourcery.com>
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)