autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Iterating over variable using AC_DEFINE to get HAVE_FOO_varitem (sim


From: Daniel Leidert
Subject: Re: Iterating over variable using AC_DEFINE to get HAVE_FOO_varitem (similar to AC_CHECK_HEADERS)
Date: Mon, 17 May 2010 21:44:31 +0200

Am Montag, den 17.05.2010, 10:18 -0600 schrieb Eric Blake:
> On 05/15/2010 06:57 AM, Daniel Leidert wrote:

[..]
> > For a project I would like to get defines for every supported languages.
> > The ALL_LINGUAS variable contains alist of language codes. Now I would
> > like to get
> > 
> > HAVE_LINGUA_$lang
> > 
> > for every languages code in the variable. 
> 
> What you are attempting doesn't make much sense to me yet.  The whole
> point of i18n is that the translation files can be maintained
> independently of the executable, and that a person can install a subset
> of the compiled .mo files according to their needs.

The rationale behind is, that the user should be able to choose the
language from the preferences. Of course it should only contain
languages shipped with the source/binary. Therefor I would like to have
something like this

ALL_LINGUAS="de fr"

config.h:
#define HAVE_LINGUA_DE
#define HAVE_LINGUA_FR

src/foo.c:
list_of_langs = add_to_list(
#ifdef HAVE_LINGUA_DE
        "Deutsch",
#endif
#ifdef HAVE_LINGUA_FR
        "Français",
#endif
#ifdef HAVE_LINGUA_NL
        "Nederlands",
#endif
        NULL);

> Therefore, any
> compile-time test that sets a variable HAVE_LINGUA_foo in relation to
> the languages on the compilation machine will most likely be out-of-date
> when you copy the executable but not the translation file to a user's
> machine.  Conversely, a translation language not available at configure
> time might later be written and installed, at which point your
> executable is already hard-coded not to use it.

That's true. But ion the above situation IMHO you cannot handle this
case. IMHO you could only add all possible languages and check, if
setting the related locale succeeds. Am I wrong?

> > I tried this piece of code:
> > 
> >> AS_FOR(
> >>         [AC_lingua],
> >>         [ac_lingua],
> >>         [$ALL_LINGUAS],
> >>         [
> >>          AC_MSG_NOTICE([Having lingua ]AC_lingua)
> >>          AH_TEMPLATE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua), [Define to 1 for 
> >> <AC_lingua> lingua support.])
> >>          AC_DEFINE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua))
> >>         ]
> >> )
> 
> AS_FOR is not (yet) documented;

I tried m4_foreach_w too. But this fails too:

> ALL_LINGUAS="de fr nl"
> m4_foreach_w(
>         [AC_lingua],
>         [$ALL_LINGUAS],
>         [
>          AC_MSG_NOTICE([Having lingua ]AC_lingua)dnl debugging
>          AH_TEMPLATE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua), [Define to 1 for ] 
> AC_lingua [ lingua support.])
>          AC_DEFINE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua))
>         ]
> )

Even if I use m4_unquote, m4_split, ... I can't get this to work. My
working solution now is this one:

> m4_define([_MY_LINGUAS], [de fr nl])
> AC_SUBST([ALL_LINGUAS], "_MY_LINGUAS")
> m4_foreach_w(
>         [AC_lingua],
>         _MY_LINGUAS,
>         [
>          AC_MSG_NOTICE([Having lingua ]AC_lingua)dnl debugging
>          AH_TEMPLATE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua), [Define to 1 for ] 
> AC_lingua [ lingua support.])
>          AC_DEFINE(AS_TR_CPP([HAVE_LINGUA_]AC_lingua))
>         ]
> )

> therefore, it is an internal macro, with
> an interface that is subject to change.  You may be better off just
> writing a normal shell loop rather than trying to use AS_FOR;

Unfortunately the shell loop didn't work for me. I tried this:

> ALL_LINGUAS="de fr nl"
> for lang in $ALL_LINGUAS
> do
>       AC_MSG_NOTICE([Having lingua $lang])dnl debugging
>       AH_TEMPLATE(AS_TR_CPP([HAVE_LINGUA_$lang]), [Define to 1 for $lang 
> lingua support.])
>       AC_DEFINE(AS_TR_CPP([HAVE_LINGUA_$lang]))
> done

It did split the variable correctly, but AH_TEMPLATES didn't seem to
work. Maybe I did something wrong (quotation maybe?)?

[..]
> Beyond that, I'm not sure what you were expecting in the resulting
> configure file.  It may be a case of under- or over-quoting some of your
> m4 constructs, but without knowing your end goal or why you thought it
> necessary to use an undocumented AS_FOR, I'm not sure what to suggest
> for fixing it.

I hope that helps to understand my intentions the the expected result.
I've attached a sample configure.ac.

Regards, Daniel

Attachment: configure.ac
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]