Re: gnulib and gettextize

[Paul Eggert]

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
>    AM_GETTEXT_NEED_NGETTEXT
>    AM_GNU_GETTEXT
> or
>    AM_GNU_GETTEXT
>    AM_GETTEXT_NEED_NGETTEXT
> 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.