Re: Patch: One version number to rule them all

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 2 Mar 2005, Zack Weinberg wrote:

> and gcov-iov.c) or has had its need for a hardcoded version number
> eliminated (gccbug, formerly gccbug.in).  I also attempted to update
> the update_version and update_web_docs maintainer scripts.

gccbug.in has more substitutions than just the version number 
(@have_mktemp_command@, @host@, @build@, @target@, 
@gcc_config_arguments@).

>  - Advice as to how to make gcc_release work with this new scheme
>    without breaking for older release branches.

I don't think gcc_release cares when generating snapshots.  For now old 
release branches use the gcc_release version on those branches, but since 
there are likely to be such release branches still live through a move to 
Subversion it would be necessary either for several gcc_release script 
versions to be adapted for Subversion or for the mainline version to 
handle older release branches and be copied to them.  For that reason, I 
think making gcc_release check whether version.c exists and update 
different files depending on whether it does is worthwhile.

>  - Help finding all the places where the documentation needs updating.

Should just be maintainer-scripts/README, branching.html, releasing.html.

>  - Pointing out any other scripts (except gcc_release) which need
>    updating.

contrib/gcc_update checks for version.c to see whether it has a GCC source 
tree, this needs changing to some other file that has always been around 
(so it can be found on any branch someone might use gcc_update for).  For 
example, gcc/tree.def.

-- 
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)