This is the mail archive of the 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: [RFC] patch libffi autoconversion

On Wed, 10 Mar 2004, Ralf Corsepius wrote:

> > You don't hardcode the GCC version number anywhere beyond gcc/version.c
> > and gcc/doc/include/gcc-common.texi.  There are far too many manual
> > release management steps as is. Ideally we'd only have the version number
> > and release status in gcc-common.texi and put those in a generated C file
> > at configuration or build time, combining those with an automatically
> > updated date to get the version string, so avoiding the need to change
> > version.c when the version number changes.
> You could do the converse: provide the version number from inside of the
> configure script and AC_SUBST it or propagate it through config-headers,
> or apply sed-magic in Makefile to regenerate version.c

That the version number is in a .texi file in CVS is a constraint arising
from the principle that update_web_docs should just need to check out the
.texi files and texinfo.tex to build the manuals, rather than needing to
configure and build all of GCC.  To reduce the stages to be followed when
the version number changes, the number of other files in CVS with the
version number should be minimised (preferably to 0).  If the version
passed to AC_INIT can be a shell expression (involving sed) to extract the
number from gcc-common.texi, that would be OK, otherwise it should be
something like [see gcc-common.texi].

(The bug report URL should be the instructions rather than a direct link to Bugzilla.)

Joseph S. Myers

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