Re: Final Subversion testing this week

["Zack Weinberg" <zackw at panix dot com>]

> > We can now identify the exact version of gcc t have simply by the
> > revision number and branch name.  So maintaining all this stuff in a
> > DATESTAMP, etc, is severe overkill when you could simply use the result
> > of "svnversion .' and commit that to a file, or do it client side).
>
> I think we want a meaningful version in the --version output regardless of
> how someone got GCC (including where what they have is not an SVN tree and
> so can't have svnversion run in it; e.g. obtained with svn export).  If a
> hook can make every commit update (on whatever branch or branches are
> affected by that commit) a checked in file with the output of svnversion
> in, in addition to the files explicitly modified by that commit, that
> would suffice.

A close approximation to that could be had by enabling keyword substitution
for DATESTAMP and changing its content to "$Rev$".  We'd then get version
strings like
"4.1.0 $Rev: 105363$ (experimental)", which I think would be fine.  The magic
for getting rid of the stamp in an official release is all in gcc/Makefile.in
and shouldn't be affected.

The catch, though, is DATESTAMP is also used to set the value of __GLIBCXX__
over in c++config.h (see libstdc++-v3/include/Makefile.am).  I'm not sure what
to do about that.

zw