On Wed, 14 Jun 2017, Iain Buclaw wrote: > > But will exgettext nevertheless extract messages from the dfrontend code, > > if the functions happen to have string arguments in the same position as > > the generic diagnostic functions do? If so, I think that should be > > disabled, to avoid putting a lot of messages in gcc.pot that won't > > actually be translated. (If actual i18n support is desired, it should be > > shared with other users of the front end, which would mean using dgettext > > to extract translations in a different domain from the default GCC one, > > and so the messages shouldn't go in gcc.pot anyway.) > > > > I would say I'm open to i18n, however upstream D probably wouldn't be. > However as it is my intention to eventually switch the dfrontend > sources to D, exgettext extracting messages would cease to be a > problem.
Well, until then you'd need to prevent exgettext from extracting the messages. > That is something that I have been meaning to handle better. I was > originally thinking something along the lines of it being determined > at configure time. Then again, it's only use is for the dfrontend to > generate a lowering of synchronized statements that looks like: You can't readily determine this at configure time. The only target libc properties that can be determined at configure time are those you can determine by examining the text of headers, since you don't have a compiler for the target at that point (gcc/ configure only tests compilers for the host and build systems), and this property is multilib-specific. I think a target hook is the right thing here. -- Joseph S. Myers jos...@codesourcery.com
