Andrew Smith a écrit :
Hi
I inherited a project that uses autotools. It didn't have any .po files
when I got it but I added a couple, so now there is this in configure.in:
dnl Add the languages which your application supports here.
ALL_LINGUAS="sv zh_TW"
AM_GLIB_GNU_GETTEXT
They compile and
On Aug 9, 2007, at 3:29 AM, Joshua Hoblitt wrote:
On Tue, Aug 07, 2007 at 08:43:54PM -0400, John W. Eaton wrote:
Ugh. Don't do it like that. Instead, write something like
your-config-header.h:
#ifdef __GNUC__
#define ATTR_MALLOC __attribute__((malloc))
#else
On 8/9/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 07, 2007 at 08:43:54PM -0400, John W. Eaton wrote:
> > Ugh. Don't do it like that. Instead, write something like
> >
> > your-config-header.h:
> >
> > #ifdef __GNUC__
> > #define ATTR_MALLOC __attribut
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andrew Smith on 8/9/2007 12:34 AM:
> They compile and install and run fine. But when I do `make dist` I end
> up with sv.gmo and zh_TW.gmo (as well as the expected sv.po, zh_TW.po)
> in my po dir. I thought these were binary and not portab
Eric Blake a écrit :
According to Andrew Smith on 8/9/2007 12:34 AM:
They compile and install and run fine. But when I do `make dist` I end
up with sv.gmo and zh_TW.gmo (as well as the expected sv.po, zh_TW.po)
in my po dir. I thought these were binary and not portable?
They are indeed binary,
Andrew Smith wrote:
>>> Would someone share why this may be happening and what I can do to avoid
>>> it?
>>
>> You don't want to avoid it, otherwise your package would not have i18n
>> support.
>>
> Yeah I meant avoid packaging them in the release tarball, I know they
> have to be compiled before t
I have another problem, which is similar. The problem is the result of
AM_CONDITIONAL. Here is my macro:
AC_DEFUN([AS_CHECK_DRIVER], [
pushdef([UP], translit([$1], [a-z], [A-Z]))dnl
pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl
AC_ARG_ENABLE([DOWN[]],
AC_HELP_STRING(
[--disable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Vincent Torri on 8/9/2007 12:11 PM:
>
> I have another problem, which is similar. The problem is the result of
> AM_CONDITIONAL. Here is my macro:
>
> AM_CONDITIONAL(BUILD_DRIVER_[]UP, test "x${use_]DOWN[}" = "xyes")
Follow the quoting
On Aug 10, 2007, at 4:57 AM, Eric Blake wrote:
According to Vincent Torri on 8/9/2007 12:11 PM:
I have another problem, which is similar. The problem is the
result of
AM_CONDITIONAL. Here is my macro:
AM_CONDITIONAL(BUILD_DRIVER_[]UP, test "x${use_]DOWN[}" = "xyes")
Follow the quoting ru
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Benoit SIGOURE on 8/9/2007 9:20 PM:
>>>
>>> AM_CONDITIONAL(BUILD_DRIVER_[]UP, test "x${use_]DOWN[}" = "xyes")
>>
>>
>> AM_CONDITIONAL([BUILD_DRIVER_[]UP, test "x${use_[]DOWN}" = "xyes"])
>
> Hum, shouldn't this be:
> AM_CONDITIONAL([BUILD
On Thu, 9 Aug 2007, Eric Blake wrote:
AM_CONDITIONAL(BUILD_DRIVER_[]UP, test "x${use_]DOWN[}" = "xyes")
Follow the quoting rule of thumb - if you don't want things expanded
immediately, then use one level of [] per () to protect the argument
collection scan, thereafter, use nested quotes to
On Thu, 9 Aug 2007, Eric Blake wrote:
Needless to say, I only typed a quick answer, rather than trying to test
it. There are two arguments to AM_CONDITIONAL, so both should be quoted.
Then you have a choice:
AM_CONDITIONAL([BUILD_DRIVER_[]UP], [...])
calls AM_CONDITIONAL with a string for t
12 matches
Mail list logo
