https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #9 from Bruno Haible <bruno at clisp dot org> ---
Jakub Jelinek wrote:
> I thought it is the gettext utilities which are supposed to verify this kind
> of stuff, but maybe it hasn't been taught about some GCC format strings yet.
Yes, that is the case: gcc-internal-format has last been updated in 2008, and
gfc-internal-format in 2009.
The reason is that GCC and GNU gettext evolve with different release cycles,
and I don't see how the format string checking (implemented in "msgfmt -c")
could be kept up-to-date.
In detail:
GCC puts out a new major release once a year, and may extend the
GCC/GFC-internal format string syntax within a release cycle and expect to
apply it to the PO files that come in at the end of the release cycle.
Whereas GNU gettext may see a new release only once in 3 years. (That happened
with gettext-0.20 and gettext-0.22.) The way it's currently implemented is that
the format string checker is contained in the "msgfmt" program (used by the
programmers and translators). The Translation Project's robot also uses the
gettext tools, but it's not a problem if the format string checking done there
is out-of-date — if and only if it would be done when a PO file gets integrated
into GCC.
Once the GCC team extends the GCC/GFC-internal format string syntax, an update
to gettext/gettext-tools/src/format-{gcc,gfc}-internal.c and
gettext/gettext-tools/tests/format-{gcc,gfc}-internal-{1,2} would be needed
(like the one Jakub just proposed, above), then a new gettext release would be
needed, and (assuming the GCC release management team does not want to wait for
the distro to pick up the new gettext release) the GCC release management team
would need to install GNU gettext from source, i.e. from the release tarball.
I don't see how things could be organized, to overcome this difference in
release cycles.
* One possible idea is to turn these two format string checkers into loadable
modules, implemented in a shared library each. But the devil is in the details:
Who would own the source code of these loadable modules? How to guarantee that
a regular gettext release contains its source code? How to handle changes in
the API of this loadable module? It would add a lot of complexity.
* Another possible idea is to let the GCC team maintain changes to
gettext/gettext-tools/src/format-{gcc,gfc}-internal.c and
gettext/gettext-tools/tests/format-{gcc,gfc}-internal-{1,2} in a branch in the
GNU gettext source repository. The GNU gettext maintainer would then merge from
that branch before preparing a new release. But - and that is the main point -
the GCC release management team could build binaries from that branch, that
they use in their (continuous or manual) integration of new incoming PO files.
* Another possible idea is for the GCC team to have a GCC/GFC-internal format
string written in some scripting language. But then, either we keep these two
format string checkers in GNU gettext as well and thus have double maintenance
effort of the same thing. Or we drop these two format string checkers from GNU
gettext, which means that the translators could no longer check their
translations with the regular "msgfmt -c" command.
Other ideas?
