This is the mail archive of the
mailing list for the GCC project.
Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Joseph S. Myers" <joseph 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: Fri, 26 Nov 2004 13:48:12 -0800
- Subject: Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305)
- References: <email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com>
"Joseph S. Myers" <firstname.lastname@example.org> 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