This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Bump version on mainline


zack@codesourcery.com (Zack Weinberg)  wrote on 26.02.05 in <87vf8esh2o.fsf@codesourcery.com>:

> 2) The recommended practice for maintaining your own branch of GCC is
>    to modify the trailing part of the version string, leaving the
>    initial bit alone to identify the upstream version you branched
>    from.  But then if you want to update to a newer version - say, if
>    you're tracking a release branch - you inevitably get a merge
>    conflict in version.c, which is irritating.

> We create two files in the top-level config/ directory.  They are
> named DATESTAMP and GCC-BASE-VER.  Their complete contents are,
> respectively, "YYYYMMDD\n" and "X.Y[.Z]\n".  For instance, today on
> mainline they would read "20050227\n" and "4.1.0\n".  (\n is a
> newline, and the quotation marks are not in the file.)

> Thoughts?

Given gcc -v output like

gcc version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5)

you might want a third file that for this version could contain
"(Debian 4.0-0pre5)\n", and be inserted in all the right places.

You might want it to be empty in CVS, or it might even be useful to make  
it read "(CVS)" in CVS, "(Snapshot)" in a snapshot, and "(Release)" in a  
released version ... maybe.

MfG Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]