Re: how to harvest translatable strings from generated files?

[Paul Pogonyshev]

Bruno Haible wrote:
> Hi,
>
> Paul Pogonyshev wrote:
> > I have a custom-format files which a parsed during build process with
> > custom tools to generate C files.  Some of these files contain translable
> > strings. Apparently, I cannot feed the custom files to `xgettext',
> > because it doesn't understand their format.
>
> Yes, and it is some effort to make 'xgettext' understand a custom format.
> It's better to generate some dummy C file, just as input for xgettext,
> such as
>
>   gettext("foo");
>   /* TRANSLATORS: ...some comment for the translators... */
>   gettext("bar");
>
> > At the same time, C files end up in
> > the build directory, which is not necessarily the same as the source
> > directory.
>
> You can either create the dummy C file in the source directory, and
> distribute it with your package. The same way as you handle the output
> from bison or flex.

This is not an option here, as some of the C files depend on `configure'
results.  Even if those with translatable strings currently don't, splitting
over it looks ugly.

> Or you can create the dummy C file in the build directory, during "make" -
> like you do with .o files -, and constrain yourself to not do "make
> update-po" or "make dist" when $builddir != $srcdir. Remember, xgettext is
> not run by a normal "make"; only when the maintainer invokes it explicitly
> through "make update-po" or "make dist".

Indeed, I missed this.  I'd like to avoid such constraint (especially since
I normally build my program in two separate directories with different
configuration), but it is of course not critical.

Are there any hopes of generalizing `POTFILES' in some way in future?  For
instance, I could write

  some/distributed/file.c
  $(top_builddir)/some/built/file.c

in `POTFILES.in' and then during conversion to `POTFILES' it would not
prepend `top_srcdir' value to lines beginning with `$(top_builddir)', but
instead replace `$(top_builddir)' with corresponding value.  Probably not
very generic, but should work.

Paul