From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Richard Sandiford <rsandifo@redhat.com>,
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)
Date: Thu, 25 Nov 2004 21:28:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.61.0411252120400.1554@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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)
next prev parent reply other threads:[~2004-11-25 21:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-25 20:47 Richard Sandiford
2004-11-25 20:50 ` Remove config.if (patch 2/4 " Richard Sandiford
2004-12-02 20:08 ` Alexandre Oliva
2004-11-25 20:54 ` Add config/gxx-include-dir.m4 (patch 3/4 " Richard Sandiford
2004-12-02 20:08 ` Alexandre Oliva
2004-12-03 10:55 ` Richard Sandiford
2004-11-25 21:05 ` Factor configure-time gcc version checks (patch 1/4 " Zack Weinberg
2004-11-25 21:28 ` Joseph S. Myers [this message]
2004-11-26 21:48 ` Zack Weinberg
2004-11-26 9:06 ` Richard Sandiford
2004-11-26 10:37 ` Andrew Haley
2004-12-01 23:08 ` DJ Delorie
2004-12-02 11:22 ` Richard Sandiford
2004-12-02 14:15 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.61.0411252120400.1554@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=binutils@sources.redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=java-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=rsandifo@redhat.com \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox