Re: multiple configure.ac's in a project?

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> 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