How can I import build-aux/po/Makefile.in.in

[Akim Demaille-3]

Hi!

I would like bison to used gnulib's build-aux/po/Makefile.in.in,
but I don't understand how I am supposed to do that.  bison's
bootstrap is sync'ed with that of gnulib (the current master).

We do have "gettext" listed in our gnulib_modules (not
"gettext-h"), and autopoint is fired, as expected, but
gnulib-tool does not override these files.  The corresponding
node of the documentation is not clear about this.

http://www.gnu.org/software/gnulib/manual/gnulib.html#gettextize-and-autopoint

I have tried to get some inspiration from the coreutils,
but they don't use gnu lib's Makefile.in.in either.

So it is unclear to me how this file should be imported
(git grep Makefile.in.in finds nothing relevant).

Thanks in advance!

[Paul Eggert]

On 04/07/2012 04:48 AM, Akim Demaille wrote:
> I have tried to get some inspiration from the coreutils,
> but they don't use gnu lib's Makefile.in.in either.

Yes they do -- gnulib-tool copies it and coreutils bootstrap.conf
tailors it.  Look for "Makefile.in.in" in those two files.

Coreutils formerly had its own copy but started
using gnulib's back in 2006.

[Bruno Haible]

Hi Akim,

> autopoint is fired, as expected, but
> gnulib-tool does not override these files.

You can at any moment of the autogen.sh or bootstrap process copy selected
files from gnulib, using a command such as

  gnulib-tool --copy-file build-aux/po/Makefile.in.in po/Makefile.in.in

Bruno

[Akim Demaille-3]

Le 7 avr. 2012 à 16:42, Paul Eggert a écrit :

> On 04/07/2012 04:48 AM, Akim Demaille wrote:
>> I have tried to get some inspiration from the coreutils,
>> but they don't use gnu lib's Makefile.in.in either.
>
> Yes they do -- gnulib-tool copies it and coreutils bootstrap.conf
> tailors it.  Look for "Makefile.in.in" in those two files.
>
> Coreutils formerly had its own copy but started
> using gnulib's back in 2006.

Hi Paul!

I must be missing something :/  In the copy I checked out
recently, and freshly bootstrapped:

commit 7e0ef7c035a4ef331dfd5019465ad00171a7b800
Author: Andreas Schwab <schwab@...>
Date:   Wed Apr 4 15:06:17 2012 +0200

    tests: avoid unnecessary subshells in misc/stty
   
    * tests/misc/stty: Don't waste a subshell to perform this:
    eval rev=\$REV_$opt.  Fix rev1,rev2 assignments similarly.

I have:

~/src/gnu/coreutils $ diff gnulib/build-aux/po/Makefile.in.in po
99c99
< all: all-@USE_NLS@
---
> all: check-macro-version all-@USE_NLS@
105,106c105,106
< CHECK_MACRO_VERSION = \
< test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
---
> check-macro-version:
> @test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
126d125
< @$(CHECK_MACRO_VERSION)
142c141
< if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null | grep -v 'libtool:' >/dev/null; then \
---
> if true; then \

and

~/src/gnu/coreutils $ diff ~/src/bison/po/Makefile.in.in po
141c141
< if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null | grep -v 'libtool:' >/dev/null; then \
---
> if true; then \


So yes, I had seen the bit that specializes that file, yet
my reading is that the coreutils do not use the copy from
gnulib, but, like Bison, the one from autopoint that does
not feature your "make -q" fixes.

What is it that I am missing?

[Akim Demaille-3]

Le 7 avr. 2012 à 19:09, Bruno Haible a écrit :

> Hi Akim,
>
>> autopoint is fired, as expected, but
>> gnulib-tool does not override these files.
>
> You can at any moment of the autogen.sh or bootstrap process copy selected
> files from gnulib, using a command such as
>
>  gnulib-tool --copy-file build-aux/po/Makefile.in.in po/Makefile.in.in

Hi Bruno!

Thanks for your answer.  Bison is using exactly gnulib's bootstrap,
so I thought that Makefile.in.in would be imported in some more
official way.  Maybe a module or something.  Or some magic (I saw
there is already some magic for runtime-po for instance).

I'll do what the coreutils do, thanks!

[Akim Demaille-3]

Hi Paul, hi all!

I would really like some help here.  I am probably missing
something, but I am under the impression that the coreutils
are using gettext's po/Makefile.in.in instead of gnulib's,
so your fixes, Paul, would not be installed–as my first
diff below attempts to show.

Since I would like Bison to use the same approach as the
Coreutils, I would be very to understand my misunderstanding.

Cheers!

        Akim


Le 9 avr. 2012 à 08:43, Akim Demaille a écrit :

>
> Le 7 avr. 2012 à 16:42, Paul Eggert a écrit :
>
>> On 04/07/2012 04:48 AM, Akim Demaille wrote:
>>> I have tried to get some inspiration from the coreutils,
>>> but they don't use gnu lib's Makefile.in.in either.
>>
>> Yes they do -- gnulib-tool copies it and coreutils bootstrap.conf
>> tailors it.  Look for "Makefile.in.in" in those two files.
>>
>> Coreutils formerly had its own copy but started
>> using gnulib's back in 2006.
>
> Hi Paul!
>
> I must be missing something :/  In the copy I checked out
> recently, and freshly bootstrapped:
>
> commit 7e0ef7c035a4ef331dfd5019465ad00171a7b800
> Author: Andreas Schwab <schwab@...>
> Date:   Wed Apr 4 15:06:17 2012 +0200
>
>    tests: avoid unnecessary subshells in misc/stty
>
>    * tests/misc/stty: Don't waste a subshell to perform this:
>    eval rev=\$REV_$opt.  Fix rev1,rev2 assignments similarly.
>
> I have:
>
> ~/src/gnu/coreutils $ diff gnulib/build-aux/po/Makefile.in.in po
> 99c99
> < all: all-@USE_NLS@
> ---
>> all: check-macro-version all-@USE_NLS@
> 105,106c105,106
> < CHECK_MACRO_VERSION = \
> < test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
> ---
>> check-macro-version:
>> @test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
> 126d125
> < @$(CHECK_MACRO_VERSION)
> 142c141
> < if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null | grep -v 'libtool:' >/dev/null; then \
> ---
>> if true; then \
>
> and
>
> ~/src/gnu/coreutils $ diff ~/src/bison/po/Makefile.in.in po
> 141c141
> < if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null | grep -v 'libtool:' >/dev/null; then \
> ---
>> if true; then \
>
>
> So yes, I had seen the bit that specializes that file, yet
> my reading is that the coreutils do not use the copy from
> gnulib, but, like Bison, the one from autopoint that does
> not feature your "make -q" fixes.
>
> What is it that I am missing?
>

[Jim Meyering]

Akim Demaille wrote:

> Hi Paul, hi all!
>
> I would really like some help here.  I am probably missing
> something, but I am under the impression that the coreutils
> are using gettext's po/Makefile.in.in instead of gnulib's,
> so your fixes, Paul, would not be installed–as my first
> diff below attempts to show.
>
> Since I would like Bison to use the same approach as the
> Coreutils, I would be very to understand my misunderstanding.

Hi Akim,

You're right that coreutils does not use gnulib's po/Makefile.in.in.
At first, I though I could fix that by adding $build_aux/po/Makefile.in.in
to $gnulib_extra_files, but that would not copy it to po/.

Instead, this is the patch I suspect we will use:
[below the patch, I've included the induced differences for coreutils]

From 0a5677642b8d9df02c05d569875bdca235084f43 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@...>
Date: Mon, 16 Apr 2012 12:13:14 +0200
Subject: [PATCH] bootstrap: use gnulib's po/Makefile.in.in, not the one from
 gettext

* build-aux/bootstrap: Use gnulib's po/Makefile.in.in, not
the one from gettext.  Reported by Akim Demaille.
---
 ChangeLog           |    4 ++++
 build-aux/bootstrap |    4 +++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 54f33e9..33f553d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2012-04-16  Jim Meyering  <meyering@...>

+ bootstrap: use gnulib's po/Makefile.in.in, not the one from gettext
+ * build-aux/bootstrap: Use gnulib's po/Makefile.in.in, not
+ the one from gettext.  Reported by Akim Demaille.
+
  maint: avoid spurious "make sc_maint" failure
  * cfg.mk (exclude_file_name_regexp--sc_trailing_blank): Also
  exempt all *.class file names, for lib/javaversion.class.
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index 31eb651..d749fe2 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2012-02-11.09; # UTC
+scriptversion=2012-04-16.10; # UTC

 # Bootstrap this package from checked-out sources.

@@ -863,6 +863,8 @@ if test $with_gettext = yes; then
     }
   ' po/Makevars.template >po/Makevars || exit 1

+  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1
+
   if test -d runtime-po; then
     # Similarly for runtime-po/Makevars, but not quite the same.
     rm -f runtime-po/Makevars
--
1.7.10.169.g146fe


=====================================================
Here are the differences induced by the patch above, i.e., by using
the po/Makefile.in.in from gnulib rather than the one from gettext:

--- po/Makefile.in.in.~1~ 2012-04-16 11:35:37.400568590 +0200
+++ po/Makefile.in.in 2012-04-16 12:01:07.293038452 +0200
@@ -96,14 +96,14 @@ CATALOGS = @CATALOGS@
  mv t-$@ $@


-all: check-macro-version all-@USE_NLS@
+all: all-@USE_NLS@

 all-yes: stamp-po
 all-no:

 # Ensure that the gettext macros and this Makefile.in.in are in sync.
-check-macro-version:
- @test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
+CHECK_MACRO_VERSION = \
+ test "$(GETTEXT_MACRO_VERSION)" = "@GETTEXT_MACRO_VERSION@" \
   || { echo "*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version $(GETTEXT_MACRO_VERSION) but the autoconf macros are from gettext version @GETTEXT_MACRO_VERSION@" 1>&2; \
        exit 1; \
      }
@@ -123,6 +123,7 @@ check-macro-version:
 # $(POFILES) has been designed to not touch files that don't need to be
 # changed.
 stamp-po: $(srcdir)/$(DOMAIN).pot
+ @$(CHECK_MACRO_VERSION)
  test ! -f $(srcdir)/$(DOMAIN).pot || \
   test -z "$(GMOFILES)" || $(MAKE) $(GMOFILES)
  @test ! -f $(srcdir)/$(DOMAIN).pot || { \

[Akim Demaille-3]

Le 16 avr. 2012 à 12:16, Jim Meyering a écrit :

> diff --git a/build-aux/bootstrap b/build-aux/bootstrap
> index 31eb651..d749fe2 100755
> --- a/build-aux/bootstrap
> +++ b/build-aux/bootstrap
> @@ -1,6 +1,6 @@
> #! /bin/sh
> # Print a version string.
> -scriptversion=2012-02-11.09; # UTC
> +scriptversion=2012-04-16.10; # UTC
>
> # Bootstrap this package from checked-out sources.
>
> @@ -863,6 +863,8 @@ if test $with_gettext = yes; then
>     }
>   ' po/Makevars.template >po/Makevars || exit 1
>
> +  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1

Actually this does not work for me (= bison).  $build_aux is
build-aux, not gnulib/build-aux, so it does not find Makefile.in.in.
It fails the same way on my checkout of coreutils (when I update its
gnulib and force the use of gnulib's bootstrap).

Actually, while at it, why not a symlink, as for the other
components of gnulib?

[Jim Meyering]

Akim Demaille wrote:

> Le 16 avr. 2012 à 12:16, Jim Meyering a écrit :
>
>> diff --git a/build-aux/bootstrap b/build-aux/bootstrap
>> index 31eb651..d749fe2 100755
>> --- a/build-aux/bootstrap
>> +++ b/build-aux/bootstrap
>> @@ -1,6 +1,6 @@
>> #! /bin/sh
>> # Print a version string.
>> -scriptversion=2012-02-11.09; # UTC
>> +scriptversion=2012-04-16.10; # UTC
>>
>> # Bootstrap this package from checked-out sources.
>>
>> @@ -863,6 +863,8 @@ if test $with_gettext = yes; then
>>     }
>>   ' po/Makevars.template >po/Makevars || exit 1
>>
>> +  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1
>
> Actually this does not work for me (= bison).  $build_aux is
> build-aux, not gnulib/build-aux, so it does not find Makefile.in.in.
> It fails the same way on my checkout of coreutils (when I update its
> gnulib and force the use of gnulib's bootstrap).

Oops.  This should work better:

diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index d749fe2..16dc15c 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2012-04-16.10; # UTC
+scriptversion=2012-04-16.16; # UTC

 # Bootstrap this package from checked-out sources.

@@ -863,7 +863,7 @@ if test $with_gettext = yes; then
     }
   ' po/Makevars.template >po/Makevars || exit 1

-  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1
+  cat $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in || exit 1

   if test -d runtime-po; then
     # Similarly for runtime-po/Makevars, but not quite the same.

> Actually, while at it, why not a symlink, as for the other
> components of gnulib?

Well, at least coreutils ends up modifying po/Makefile.in.in further,
via this from bootstrap.conf, which made me prefer to copy rather
than to link:

bootstrap_epilogue()
{
  # Since this is a "GNU" package, replace this line
  #   if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null \
  #      | grep -v 'libtool:' >/dev/null; then
  # with this:
  #   if true; then
  # Why?  That pipeline searches all files in $(top_srcdir), and if you
  # happen to have large files (or apparently large sparse files), the
  # first grep may well run out of memory.
  perl -pi -e 's/if LC_ALL=C grep .GNU .PACKAGE.*; then/if true; then/' \
    po/Makefile.in.in

[Jim Meyering]

Akim Demaille wrote:

> Le 16 avr. 2012 à 12:16, Jim Meyering a écrit :
>
>> diff --git a/build-aux/bootstrap b/build-aux/bootstrap
>> index 31eb651..d749fe2 100755
>> --- a/build-aux/bootstrap
>> +++ b/build-aux/bootstrap
>> @@ -1,6 +1,6 @@
>> #! /bin/sh
>> # Print a version string.
>> -scriptversion=2012-02-11.09; # UTC
>> +scriptversion=2012-04-16.10; # UTC
>>
>> # Bootstrap this package from checked-out sources.
>>
>> @@ -863,6 +863,8 @@ if test $with_gettext = yes; then
>>     }
>>   ' po/Makevars.template >po/Makevars || exit 1
>>
>> +  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1
>
> Actually this does not work for me (= bison).  $build_aux is
> build-aux, not gnulib/build-aux, so it does not find Makefile.in.in.
> It fails the same way on my checkout of coreutils (when I update its
> gnulib and force the use of gnulib's bootstrap).

Hah.  I realized why that change worked for me.
Remember how I said I'd first tried using $gnulib_extra_files?
Well, that had added a symlink in my coreutils dir from
build-aux/po/Makefile.in.in to the file in gnulib/...
With that, my patch worked.

> Actually, while at it, why not a symlink, as for the other
> components of gnulib?

From 1a0e0aefd4b1fbef0c6e5d990bc01499fd153a0d Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@...>
Date: Mon, 16 Apr 2012 18:50:42 +0200
Subject: [PATCH] bootstrap: really use gnulib's po/Makefile.in.in

* build-aux/bootstrap: Correct the source file name in previous change.
Reported by Akim Demaille.
---
 ChangeLog           |    4 ++++
 build-aux/bootstrap |    4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8817dab..c08ba76 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2012-04-16  Jim Meyering  <meyering@...>

+ bootstrap: really use gnulib's po/Makefile.in.in
+ * build-aux/bootstrap: Correct the source file name in previous change.
+ Reported by Akim Demaille.
+
  configmake: correct minor inconsistency in Makefile rule
  * modules/configmake (Makefile.am): All other rules like this one
  run the final "mv -f ..." in the same backslash-continued command
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index d749fe2..16dc15c 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2012-04-16.10; # UTC
+scriptversion=2012-04-16.16; # UTC

 # Bootstrap this package from checked-out sources.

@@ -863,7 +863,7 @@ if test $with_gettext = yes; then
     }
   ' po/Makevars.template >po/Makevars || exit 1

-  cat $build_aux/po/Makefile.in.in > po/Makefile.in.in || exit 1
+  cat $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in || exit 1

   if test -d runtime-po; then
     # Similarly for runtime-po/Makevars, but not quite the same.
--
1.7.10.169.g146fe

[eblake]

On 04/07/2012 05:48 AM, Akim Demaille wrote:
> Hi!
>
> I would like bison to used gnulib's build-aux/po/Makefile.in.in,
> but I don't understand how I am supposed to do that.  bison's
> bootstrap is sync'ed with that of gnulib (the current master).

Revisiting this topic, WHY are we trying to use gnulib's
build-aux/po/Makefile.in.in?  Either it matches the version of
Makefile.in.in that gettextize would have installed for you in the first
place, or it doesn't match and you face the problems that hit libvirt
this week.  Can I get some more justification for why this change was
made in the first place, in case we decide that it is better to revert
Jim's patches to bootstrap that force the latest Makefile.in.in into a
project?

>
> We do have "gettext" listed in our gnulib_modules (not
> "gettext-h"), and autopoint is fired, as expected, but
> gnulib-tool does not override these files.  The corresponding
> node of the documentation is not clear about this.

Ah, maybe this explains it.  If you use the 'gettext-h' module, like
libvirt does, you want to support arbitrary gettext versions (including
0.17); if you use the 'gettext' module, then you are stating that you
want to use the latest and greatest gettext, even if that means it is
newer than the current stable gettext release.  That is, maybe it sounds
like we should _only_ be copying the Makefile.in.in into the project if
the 'gettext' module is in use, which means the copy should not be done
as part of 'bootstrap', but as part of 'gnulib-tool' installing the
'gettext' module.

--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[Akim Demaille-3]

Hi Eric,

Sorry for the delays,

Le 25 avr. 2012 à 19:36, Eric Blake a écrit :

> On 04/07/2012 05:48 AM, Akim Demaille wrote:
>> Hi!
>>
>> I would like bison to used gnulib's build-aux/po/Makefile.in.in,
>> but I don't understand how I am supposed to do that.  bison's
>> bootstrap is sync'ed with that of gnulib (the current master).
>
> Revisiting this topic, WHY are we trying to use gnulib's
> build-aux/po/Makefile.in.in?

To address a bug in gettext that hits the packages that use it:
install-pdf and such other recursive targets are not supported.

See http://lists.gnu.org/archive/html/bug-gettext/2011-05/msg00008.html
for the first report, and
http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00003.html
for its recent reactivation.

> Either it matches the version of
> Makefile.in.in that gettextize would have installed for you in the first
> place, or it doesn't match and you face the problems that hit libvirt
> this week.  Can I get some more justification for why this change was
> made in the first place, in case we decide that it is better to revert
> Jim's patches to bootstrap that force the latest Makefile.in.in into a
> project?

The point is to fix a bug in Bison.

http://lists.gnu.org/archive/html/bug-bison/2011-05/msg00008.html

[eblake]

On 05/01/2012 11:19 PM, Akim Demaille wrote:
> Hi Eric,
>
> Sorry for the delays,

No problem.

>
> Le 25 avr. 2012 à 19:36, Eric Blake a écrit :
>
>> On 04/07/2012 05:48 AM, Akim Demaille wrote:
>>> Hi!
>>>
>>> I would like bison to used gnulib's build-aux/po/Makefile.in.in,
>>> but I don't understand how I am supposed to do that.  bison's
>>> bootstrap is sync'ed with that of gnulib (the current master).
>>
>> Revisiting this topic, WHY are we trying to use gnulib's
>> build-aux/po/Makefile.in.in?
>
> To address a bug in gettext that hits the packages that use it:
> install-pdf and such other recursive targets are not supported.
>
> See http://lists.gnu.org/archive/html/bug-gettext/2011-05/msg00008.html
> for the first report, and
> http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00003.html
> for its recent reactivation.

I think I figured it out, and that we reached an acceptable compromise:
if you _want_ the latest and greatest gettext support, use the 'gettext'
module, and get Makefile.in.in from gnulib; if you want stable gettext
support (and don't mind GNU Coding Standard compliance), use the
'gettext-h' module and get Makefile.in.in from autopoint instead.

https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00164.html

Meanwhile, no one ever reviewed my proposed doc patch:

https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00167.html

--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[Jim Meyering]

Eric Blake wrote:
...
> Meanwhile, no one ever reviewed my proposed doc patch:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00167.html

Links to mailman-archived messages are hard to read
the moment they contain a few "@" (address@obfuscated) signs,
so texinfo is much easier to read via e.g., a gmane link:

  http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/30488

That patch/alternate-approach seems reasonable.
I read through it and didn't see any problem.

[Akim Demaille-3]

Le 8 mai 2012 à 08:50, Jim Meyering a écrit :

> Eric Blake wrote:
> ...
>> Meanwhile, no one ever reviewed my proposed doc patch:
>>
>> https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00167.html
>
> Links to mailman-archived messages are hard to read
> the moment they contain a few "@" (address@obfuscated) signs,
> so texinfo is much easier to read via e.g., a gmane link:
>
>  http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/30488

Indeed, thanks!  Can't mailman be fixed?

> That patch/alternate-approach seems reasonable.
> I read through it and didn't see any problem.

There is small left over at the end of this paragraph.

+@item
+Determine the oldest version of @code{gettext} that you intend to
+support during development (at this time, gnulib recommends going no
+older than version 0.17).  Run @code{autopoint} (not
+@code{gettextize}) to copy infrastructure into place (newer versions
+of gettext will install the older infrastructure that you requested).
+at the time the Gnulib snapshot was taken.
+