Re: Gratuitous reconfigures and rebuilds

[Zack Weinberg <zack at codesourcery dot com>]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> Ohhhhh. :-(  That root issue.  I would *love* to address that issue.  
> There is code in top level configure.in to pass something horrifying 
> known as --with-gcc-version-trigger=${srcdir}/gcc/version.c
>
> config.status in the Makefiles for gcc and libf2c depends on this 
> gcc_version_trigger, which is gcc/version.c.
>
> In other words, they reconfigure themselves daily because they have 
> specific code to do so, and have for a long time.
>
> I haven't touched that code.  I'd love to, since it seems mildly insane 
> to me, but I haven't wanted to mess with it, since I don't know what 
> it's doing there in the first place.

I remember tracing this down once.  One of the reasons it happens is,
gcc/version.c is almost the only place in the source tree where GCC's
actual version number (the "3.2.1" bit) is recorded.  We install stuff
in lib/gcc-lib/TARGET/VERSION, so the Makefile has to know what the
actual version number is.  Thus the configure script greps version.c
for it and propagates it to an @-substitution.  I suspect that libf2c
wants to do the same thing.  Of course this may not be the only
reason.

My idea of the right fix for this would be to take that piece of the
version number out of version.c and put it in configure.in, perhaps
along the lines of the way bfd/configure.in does it.  Then the
config.status:version.c dependency goes away.  I believe it would also
allow us to get rid of a bit more duplication of the version number,
e.g. in doc/include/gcc-common.texi (which could be made an .in file)

This does leave us wondering how to get the version number into
version_string for display purposes.  It would be easy with C89 string
literal concatenation, of course.

zw