Paul Eggert wrote: > what is the > recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool, > and autopoint/autoreconf in such a way that you don't get the > following files into your m4 directory afterwards? > > 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. -> Can we assume automake-1.9 or newer with gnulib? It was released two years ago and has seen numerous bugfix releases since then. But then there is Claudio Fontana, who asked for AM_CPPFLAGS += -I$(top_builddir)/intl so that he can continue shipping the intl/ directory; in this case, the AM_GNU_GETTEXT invocation needs to be different, and the list of *.m4 files needs to be complete. 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. Another problem is what to do with the second argument of AM_GNU_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"? Bruno