[4.5] [RFC] Move line-map.* to its own library (libloc)
Joseph S. Myers
joseph@codesourcery.com
Sun Nov 16 20:07:00 GMT 2008
On Sun, 16 Nov 2008, Manuel López-Ibáñez wrote:
> 2008/11/15 Joseph S. Myers <joseph@codesourcery.com>:
> > On Sat, 15 Nov 2008, Ralf Wildenhues wrote:
> >
> >> # Rule for regenerating the message template.
> >> $(PACKAGE).pot: po/$(PACKAGE).pot
> >
> > I see in this version there is a new translation domain. (The original
>
> I just copied bits from libcpp until it worked. I don't think libloc
> needs any translation stuff.
I would suggest in fact: if any host-side code moves to a separate
library, even if the library has messages needing translation it should
*not* get its own translation domain unless and until some non-GCC
software starts using the library. Instead, exgettext should be taught to
find the relevant source files if needed (or the gettext invocation for
cpplib should be so taught, if applicable), so the messages remain in the
gcc or cpplib domains.
> + fprintf (stderr, _("In file included from %s:%u"),
> + map->to_file, LAST_SOURCE_LINE (map));
> +
> ...
> + fprintf (stderr, _(",\n from %s:%u"),
> + map->to_file, LAST_SOURCE_LINE (map));
>
> This function probably does not belong to libloc but to a shared
> diagnostics/pretty-printer library but since that doesn't exist yet,
> meanwhile, it would need to be moved somewhere else.
I don't think it belongs to such a shared library, because it is specific
to the concepts of the C/C++ preprocessor. Other languages may have
different concepts for nested contexts in which a diagnostic is given, in
which case different text will be needed.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Gcc-patches
mailing list