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


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

> If the number of locations of the version number are to be reduced
> further, either the unique location should be gcc-common.texi or
> update_web_docs needs to be updated to generate whatever generated
> .texi file gets the version number when building online docs.

I have had the following idea for version numbers floating around in
my head for some time now.  It attempts to address the following
problems:

0) We have the base version number in at least two places, version.c
   and gcc-common.texi.

1) The version number is propagated from version.c to several other
   places by configure.  This means that config.status has a
   dependency on version.c, which in turn means that the daily bump of
   the datestamp is another cause of having the entire world rebuilt
   because you did a cvs update in your source directory.

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.

3) The mechanism for updating the datestamp is complicated and
   fragile (it broke, for instance, when version_string was changed
   from a char* to a char[]).

The plan:

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

version.c is then changed to read

const char version_string[] = BASE_VER " " DATESTAMP " (experimental)";

with the commentary above adjusted to match, and is now compiled as

version.o: version.c version.h $(srcdir)/../config/DATESTAMP \
           $(srcdir)/../config/GCC-BASE-VER
        $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
              -DBASE_VER="\"`cat $(srcdir)/../config/GCC-BASE-VER`\"" \
              -DDATESTAMP="\"`cat $(srcdir)/../config/DATESTAMP`\"" \
              -c $(srcdir)/version.c $(OUTPUT_OPTION)

Similarly, gcc-common.texi is now generated from gcc-common.texi.in
(this is necessary because texi2dvi does not support command line
@set) by the Makefile (not! by configure), doing something like

gcc-common.texi: gcc-common.texi.in
        sed -e 's/@version@/$(shell cat $(srcdir)/../config/GCC-BASE-VER)/' \
            $< > $@

And similarly with all the other places that need the version number.
I'd treat gcccbug.in as a special case - rename it to gccbug, and have
it determine the default version string at runtime via 
"gcc --version | head -1" or equivalent.

Thoughts?

zw


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