Bruno Haible <bruno@xxxxxxxxx> 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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
