[Bug other/13485] [3.4 regression] Generated files no longer get messages extracted

["jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-01-14 17:21 -------
Subject: Re:  [3.4 regression] Generated files no longer
 get messages extracted

On Wed, 14 Jan 2004, kcook at gcc dot gnu dot org wrote:

> How often is po/gcc.pot supposed to be regenerated?
> 
> If it is only upon every {pre-,}release then it doesn't seem that we have a
> problem since {pre-,}releases are run via --enable-generated-files-in-srcdir.  

It is regenerated whenever a new release branch is created (long before
any prereleases), and the first branch snapshot (not a prerelease) is
submitted to the TP.  It is also regenerated from time to time on
mainline, including when there have been changes to translation machinery
improving the set of messages that get extracted.  Mainline gcc.pot
doesn't *at present* get submitted to the TP, but it might in future
(though they don't want automated submission of weekly snapshots): they
can handle having multiple lines of development, each of which is relevant
for translation, it may just dilute translator effort.  It is also 
regenerated just before releases.  See translation.html, releasing.html, 
branching.html.

Automatic generation in the release script would need to be done from the
*first* checkout - the one that updates the ChangeLogs - to get the
release tag on the correct version in CVS.  At present this first checkout
doesn't get built at all.  (The RM can regenerate gcc.pot simply by doing
an ordinary manual build - probably not using
--enable-generated-files-in-srcdir - interrupting it once the gcc
directory is building and doing make gcc.pot.)

In general rebuilding gcc.pot should be considered an ordinary maintainer 
action, though most maintainers may not do it much, that should work from 
any ordinary build rather than requiring special configure options.  In 
particular it shouldn't require maintainers to clutter up their CVS 
checkouts with various generated files.

> If this is correct, then without any difficulty we could add options.c to the
> list of generated-files-in-srcdir so we could eliminate its hardcoding in exgetext.

There's no normal need for it in srcdir (as we do reasonably require GCC
builders to have awk).

I hope that changing

po-generated: ...

to

po_generated += ...

should be the main part of what's needed to fix the problem without making
it more difficult to regenerate gcc.pot.

> Thinking further this could be followed by a automagic cvs commit of po/gcc.pot
> by the gcc_release script.

As noted, that sort of thing would require the script to run a build from
the first checkout as well as the second.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13485