multiple configure.ac's in a project?
Simon Josefsson
In GnuTLS I'm using several configure.ac:
configure.ac
lib/configure.ac
libextra/configure.ac
The reason for this was that gnulib worked better with this setup, but
there are other arguments as well (although, alas, not autoreconf
speed!).
However, this complicates the gettext setup. There is one "gnutls"
gettext domain.
The options appears to be:
1) Use one gettext domain per configure.ac.
In other words, there will be:
"gnutls" in po/ for command line tools
"libgnutls" in lib/po for libgnutls messages
"libgnutls-extra" in libextra/po for libgnutls-extra messages
Is this what you would recommend?
I would have to ask the translation team to rename the current
"gnutls" domain into "libgnutls" since currently only messages from
the library is in the "gnutls" domain.
This approach appears sub-optimal to me, but maybe you have more
insight to this.
2) Use one "gnutls" gettext domain for the entire project, putting the
translation files in the top-level po/.
This leads to problems in the code in lib/ and libextra/: ENABLE_NLS
is not set, so the gettext function is null.
If I add AM_GNU_GETTEXT to lib{,extra}/configure.ac it will require
that directories lib/po/ and libextra/po/ exists -- since the macro
and the autopoint tool requires that.
Further, I couldn't seem to get it to generate lib/po/Makefile and
libextra/po/Makefile, it seems as if the autoconf rule to work in a
po/ directory was satisfied after creating the top-level po/Makefile.
How should code in lib/ and libextra/ use the gettext function?
Thanks,
/Simon
Bruno Haible
> In GnuTLS I'm using several configure.ac:
>
> configure.ac
> lib/configure.ac
> libextra/configure.ac
>
> The reason for this was that gnulib worked better with this setup, but
> there are other arguments as well (although, alas, not autoreconf
> speed!).
>
> However, this complicates the gettext setup. There is one "gnutls"
> gettext domain.
>
> The options appears to be:
>
> 1) Use one gettext domain per configure.ac.
>
> In other words, there will be:
>
> "gnutls" in po/ for command line tools
> "libgnutls" in lib/po for libgnutls messages
> "libgnutls-extra" in libextra/po for libgnutls-extra messages
>
> Is this what you would recommend?
As long as there is no significant overlap between the message strings
in the three subprojects, yes, I can recommend this PO files structure.
> I would have to ask the translation team to rename the current
> "gnutls" domain into "libgnutls" since currently only messages from
> the library is in the "gnutls" domain.
Yes, you would have to ask the TP to do this. The TP knows how to
deal with this, and how to use the 'msgmerge' and 'msgattrib' programs
for splitting up the PO files from the last release.
> This approach appears sub-optimal to me, but maybe you have more
> insight to this.
What are the drawbacks that you see?
> 2) Use one "gnutls" gettext domain for the entire project, putting the
> translation files in the top-level po/.
>
> This leads to problems in the code in lib/ and libextra/: ENABLE_NLS
> is not set, so the gettext function is null.
>
> If I add AM_GNU_GETTEXT to lib{,extra}/configure.ac
Yes, you will have to use AM_GNU_GETTEXT in each of the three configure.acs,
regardless of which PO files structure you choose.
> it will require
> that directories lib/po/ and libextra/po/ exists -- since the macro
> and the autopoint tool requires that.
The AM_GNU_GETTEXT macro does not require a PO directory. It can, as well,
work with any number of PO directories.
And you would not need 'autopoint' in these two subdirectories - just use
the 'gettext' module from gnulib.
> How should code in lib/ and libextra/ use the gettext function?
Libraries should use the dgettext() function, not the gettext() function.
To make it easy for you, gnulib has a module 'gettext-h' which will do
the right thing once you define the C macro DEFAULT_TEXT_DOMAIN through
the AM_CPPFLAGS variable in lib/Makefile.am and libextra/Makefile.am.
Bruno
Simon Josefsson
> Simon Josefsson wrote:
>> In GnuTLS I'm using several configure.ac:
>>
>> configure.ac
>> lib/configure.ac
>> libextra/configure.ac
>>
>> The reason for this was that gnulib worked better with this setup, but
>> there are other arguments as well (although, alas, not autoreconf
>> speed!).
>>
>> However, this complicates the gettext setup. There is one "gnutls"
>> gettext domain.
>>
>> The options appears to be:
>>
>> 1) Use one gettext domain per configure.ac.
>>
>> In other words, there will be:
>>
>> "gnutls" in po/ for command line tools
>> "libgnutls" in lib/po for libgnutls messages
>> "libgnutls-extra" in libextra/po for libgnutls-extra messages
>>
>> Is this what you would recommend?
>
> As long as there is no significant overlap between the message strings
> in the three subprojects, yes, I can recommend this PO files structure.
Aha! This approach appears simplest for me as well, so if you think it
is a good idea I will try it.
>> I would have to ask the translation team to rename the current
>> "gnutls" domain into "libgnutls" since currently only messages from
>> the library is in the "gnutls" domain.
>
> Yes, you would have to ask the TP to do this. The TP knows how to
> deal with this, and how to use the 'msgmerge' and 'msgattrib' programs
> for splitting up the PO files from the last release.
I think they could just rename the current "gnutls" domain to
"libgnutls". So far only the libgnutls library contains translated
messages, the tools and libgnutls-extra aren't translated yet.
>> This approach appears sub-optimal to me, but maybe you have more
>> insight to this.
>
> What are the drawbacks that you see?
That I create potentially many gettext domains. I (perhaps incorrectly)
assumed that is a bad thing and creates more work for the translation
project and more work for distribution packagers.
For GNU SASL I do use this approach, and there is a "gsasl" domain and a
"libgsasl" domain. That has worked fine for me, but it doubles the
number of files under /usr/share/locale. For GnuTLS, this approach
would triple the number of files installed under /usr/share/locale since
there would be "gnutls", "libgnutls", and "libgnutls-extra". The GnuTLS
team have considered adding a "libgnutls-krb5" as well, and there could
be several more libraries in the future (libgnutls-pkcs11,
libgnutls-openpgp). On the other hand, it is not clear that all of
these libraries will need translations -- the libgnutls-extra doesn't
right now. So in practice I guess there will only be "libgnutls" and
"gnutls" right now.
Do you believe this drawbacks is benign? If so I'd be happy to propose
the split to the TP and implement it -- I'll just mimic what I've done
in GNU SASL.
>> 2) Use one "gnutls" gettext domain for the entire project, putting the
>> translation files in the top-level po/.
>>
>> This leads to problems in the code in lib/ and libextra/: ENABLE_NLS
>> is not set, so the gettext function is null.
>>
>> If I add AM_GNU_GETTEXT to lib{,extra}/configure.ac
>
> Yes, you will have to use AM_GNU_GETTEXT in each of the three configure.acs,
> regardless of which PO files structure you choose.
Ok. That is what I tried.
>> it will require
>> that directories lib/po/ and libextra/po/ exists -- since the macro
>> and the autopoint tool requires that.
>
> The AM_GNU_GETTEXT macro does not require a PO directory. It can, as well,
> work with any number of PO directories.
The macro calls AM_PO_SUBDIRS which do create a PO directory. This
leads to an error:
Makefile.am:25: AM_GNU_GETTEXT used but `po' not in SUBDIRS
autoreconf: automake failed with exit status: 1
> And you would not need 'autopoint' in these two subdirectories - just use
> the 'gettext' module from gnulib.
Not gettext-h? If I get past the above problem I'll try it. Right now
I use the gettext-h module in top-level and lib/.
>> How should code in lib/ and libextra/ use the gettext function?
>
> Libraries should use the dgettext() function, not the gettext() function.
> To make it easy for you, gnulib has a module 'gettext-h' which will do
> the right thing once you define the C macro DEFAULT_TEXT_DOMAIN through
> the AM_CPPFLAGS variable in lib/Makefile.am and libextra/Makefile.am.
Right, I am already aware of this part. The problem was in linking to
the library that provides the dgettext symbol. I couldn't get
AM_GNU_GETTEXT to work in lib/ and libextra/.
/Simon
Ralf Wildenhues
Hello Bruno, Simon,
* Simon Josefsson wrote on Tue, Mar 31, 2009 at 02:41:34PM CEST:
> Bruno Haible <br...@clisp.org> writes:
> > Simon Josefsson wrote:
> >> 2) Use one "gnutls" gettext domain for the entire project, putting the
> >> translation files in the top-level po/.
> >>
> >> This leads to problems in the code in lib/ and libextra/: ENABLE_NLS
> >> is not set, so the gettext function is null.
> >>
> >> If I add AM_GNU_GETTEXT to lib{,extra}/configure.ac
> >
> > Yes, you will have to use AM_GNU_GETTEXT in each of the three configure.acs,
> > regardless of which PO files structure you choose.
> >> it will require
> >> that directories lib/po/ and libextra/po/ exists -- since the macro
> >> and the autopoint tool requires that.
> >
> > The AM_GNU_GETTEXT macro does not require a PO directory. It can, as well,
> > work with any number of PO directories.
>
> The macro calls AM_PO_SUBDIRS which do create a PO directory. This
> leads to an error:
>
> Makefile.am:25: AM_GNU_GETTEXT used but `po' not in SUBDIRS
> autoreconf: automake failed with exit status: 1
I'm trying to find out whether this is an error in the Automake logic
that deals with these macros. automake will warn/error (use -Wno-syntax
to avoid an error) only if a `po' directory exists. See the comment and
code in the handle_gettext function in automake.in:
# Perform some sanity checks to help users get the right setup.
# We disable these tests when po/ doesn't exist in order not to disallow
# unusual gettext setups.
#
# Bruno Haible:
# | The idea is:
# |
# | 1) If a package doesn't have a directory po/ at top level, it
# | will likely have multiple po/ directories in subpackages.
# |
# | 2) It is useful to warn for the absence of intl/ if AM_GNU_GETTEXT
# | is used without 'external'. It is also useful to warn for the
# | presence of intl/ if AM_GNU_GETTEXT([external]) is used. Both
# | warnings apply only to the usual layout of packages, therefore
# | they should both be disabled if no po/ directory is found at
# | top level.
if (-d 'po')
{
my @subdirs = $subdirs->value_as_list_recursive;
msg_var ('syntax', $subdirs,
"AM_GNU_GETTEXT used but `po' not in SUBDIRS")
if ! grep ($_ eq 'po', @subdirs);
[...]
Is that sufficient, or should this somehow be adjusted to fix the case
Simon has experienced?
Thanks,
Ralf