Re: Patch: One version number to rule them all

[Zack Weinberg <zack at codesourcery dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

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

Harrumph.  Not sure how I missed that.

Do we need to keep this program around?  It appears to be designed for
use with GNATS, which we haven't used for years.

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

version.c doesn't stop existing, but I take your point.


>>  - Help finding all the places where the documentation needs updating.
>
> Should just be maintainer-scripts/README, branching.html, releasing.html.

The other side of this is - never having used any of these scripts -
I'm not at all sure what to say the procedure is now.

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

see above.

zw