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