Re: Factor configure-time gcc version checks (patch 1/4 for PR 7305)

[Zack Weinberg <zack@codesourcery.com>]

"Joseph S. Myers" <joseph@codesourcery.com> 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