---

3.11 Caveat: gettextize and autopoint users

The programs gettextize and autopoint, part of GNU gettext, import or update the internationalization infrastructure. Some of this infrastructure, namely ca. 20 Autoconf macro files and the config.rpath file, is also contained in Gnulib and may be imported by gnulib-tool. The use of gettextize or autopoint will therefore overwrite some of the files that gnulib-tool has imported, and vice versa.

Avoiding to use gettextize (manually, as package maintainer) or autopoint (as part of a script like autoreconf or autogen.sh) is not the solution: These programs also import the infrastructure in the po/ and optionally in the intl/ directory.

The copies of the conflicting files in Gnulib are more up-to-date than the copies brought in by gettextize and autopoint. When a new gettext release is made, the copies of the files in Gnulib will be updated immediately.

The choice of which version of gettext to require depends on the needs of your package. For a package that wants to comply to GNU Coding Standards, the steps are:

1. When you run gettextize, always use the gettextize from the matching GNU gettext release. For the most recent Gnulib checkout, this is the newest release found on https://ftp.gnu.org/gnu/gettext/. For an older Gnulib snapshot, it is the release that was the most recent release at the time the Gnulib snapshot was taken.
2. After running gettextize, invoke gnulib-tool and import the gettext module. Also, copy the latest version of gnulib’s build-aux/po/Makefile.in.in to your po/ directory (this is done for you if you use gnulib’s autogen.sh script).
3. If you get an error message like *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version ... but the Autoconf macros are from gettext version ..., it means that a new GNU gettext release was made, and its Autoconf macros were integrated into Gnulib and now mismatch the po/ infrastructure. In this case, fetch and install the new GNU gettext release and run gettextize followed by gnulib-tool.

On the other hand, if your package is not as concerned with compliance to the latest standards, but instead favors development on stable environments, the steps are:

1. Determine the oldest version of gettext that you intend to support during development (at this time, gnulib recommends going no older than version 0.17). Run autopoint (not gettextize) to copy infrastructure into place (newer versions of gettext will install the older infrastructure that you requested).
2. Invoke gnulib-tool, and import the gettext-h module.

Regardless of which approach you used to get the infrastructure in place, the following steps must then be used to preserve that infrastructure (gnulib’s autogen.sh script follows these rules):

1. When a script of yours run autopoint, invoke gnulib-tool afterwards.
2. When you invoke autoreconf after gnulib-tool, make sure to not invoke autopoint a second time, by setting the AUTOPOINT environment variable, like this:

   $ env AUTOPOINT=true autoreconf --install