Paul Eggert wrote: > what is the > recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool, > and autopoint/autoreconf ... autopoint brings in > yet another (incompatible) copy of them.
Currently, there is a general problem: After a release is made, if users do a "gnulib-tool --update", they will receive a newer gettext.m4 that may be incompatible with the po/Makefile.in.in. I'm working with two of the automake maintainers to transform po/Makefile.in.in into a po/Makefile.am file; this will fix this problem. A similar problem could also occur if the gettext.m4 macro in gnulib deviates too much from what is in the latest gettext release. I'm trying to limit this problem by moving to gnulib only "stable" changes. > 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 > > These files are unnecessary in coreutils, because of the [external], > and yet they're listed in modules/gettext Yes. How could this be fixed? If we put the AM_GNU_GETTEXT([external],...) invocation into the gnulib module description, how do people specify the arguments passed to AM_GNU_GETTEXT? > It also comments out this line: > > AM_CPPFLAGS += -I$(top_builddir)/intl > > to simplify the output of "make". Such a minor modification of a module description can be accommodated through a .diff file and the --local-dir option. Bruno
