[Top][All Lists]

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

Re: gnulib and gettextize

From: Paul Eggert
Subject: Re: gnulib and gettextize
Date: Tue, 29 Aug 2006 07:34:01 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

>>    glibc2.m4 intdiv0.m4 inttypes-h.m4 inttypes-pri.m4 lcmessage.m4
>>    lock.m4 printf-posix.m4 size_max.m4 uintmax_t.m4 ulonglong.m4
>>    visibility.m4 xsize.m4
> Assuming aclocal-1.9 or newer, I think we could remove these files
> from the modules/gettext description.

That assumption sounds fine to me.

> This suggests that we might have two gettext modules: A 'gettext-external'
> and a 'gettext-included'. Which brings up the question that always occurs
> at some point in a system with dependencies:
> -> Should gnulib-tool support "alternative modules", each of them satisfying
>   a certain dependency? For example, 'error' depends on 'gettext', but
>   'gettext' is one of two or more alternatives.

It would be nice to have this feature -- it's one I've wanted before,
for other things -- but it would be some work.  I think gettext could
get by without having this feature, though.  No module depends on
'gettext', so it'd be OK if we had multiple flavors of 'gettext'.
('error' depends on 'gettext-h', not 'gettext'.)

> Question to the autoconf experts: Is it possible to write a macro
> AM_GETTEXT_NEED_NGETTEXT such that whenever a user writes
> or
> the AM_GNU_GETTEXT macro "knows" that a AM_GETTEXT_NEED_NGETTEXT invocation
> exists elsewhere? So, a kind of "backward propagation"?

Nothing comes to me off the top of my head.  I suppose the actual work
could be "deferred to the end" but I'm sort of waving my hands here.

reply via email to

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