Jonathan Wakely <jwakely@redhat.com> writes:
> [...snip...]
> It looks like this will regenerate the bits/version.h file if it's older
> than the definitions or the autogen template, right?
>
> Generally we don't want to touch anything in the source tree as part of a
> normal build. It's OK to do that when configured with
> --enable-maintainer-mode (which nobody working on libstdc++ actually uses,
> because it causes problems IME) or via a dedicated target which is not
> built by default (e.g. doc/Makefile.am has the doc-html-docbook-regenerate
> target, which is isn't a prereq of any other targets so it's only run if
> you explicitly request it).
>
> The problem with modifying the source tree as part of a normal build is
> that it might be on read-only media, and so the build will fail if this
> target can't be updated. We would also want to add the version.h header to
> the contrib/gcc_update script that updates the timestamps of generated
> files, so that they are always newer than their prereqs.
>
> Maybe the best option here is to assume that version.h is always up to
> date, and add a custom target to regen it manually, which we can run after
> editing the .def or .tpl files. What do you think?

Ah, I wasn't aware of this concern.  I'll make it a phony target, yeah.

> My only other concern with this patch is that I don't speak lisp so the
> Guile code in version.tpl is opaque and unmaintainable for me. That is
> fixable though.

The algorithm the code implements is quite simple, it just verifies that
the three numeric fields associated with each FTM are in a non-ascending
order (which ensures that the most broad option comes last in the
#if/#elif chain).  It's a sanity check that's caught a couple of
transcription errors I made during the initial conversion.
-- 
Arsen Arsenović