Simon Josefsson asked on 2007-12-03:
> 1) Is it guaranteed that replacing the gettext M4 files with those in
> gnulib will work with the gettext version installed?
>
> 2) Is it guaranteed that replacing the gnulib M4 files with those in
> gettext will work with other gnulib macros?
>
> In other words, is there a hidden dependency between which gnulib and
> gettext version I am using?
>
> And of course the final question, what is the recommended way to handle
> the code-overlap between gnulib and gettextize in a project?
I've now added a bit of documentation that should answer these questions:
2008-03-23 Bruno Haible <[EMAIL PROTECTED]>
* doc/gnulib-tool.texi (gettextize and autopoint): New section.
*** doc/gnulib-tool.texi.orig 2008-03-23 20:12:25.000000000 +0100
--- doc/gnulib-tool.texi 2008-03-23 20:10:50.000000000 +0100
***************
*** 32,37 ****
--- 32,38 ----
* Modified imports:: Changing the import specification.
* Simple update:: Tracking Gnulib development.
* Source changes:: Impact of Gnulib on your source files.
+ * gettextize and autopoint:: Caveat: @code{gettextize} and
@code{autopoint} users!
* Localization:: Handling Gnulib's own message translations.
* VCS Issues:: Integration with Version Control Systems.
@end menu
***************
*** 371,376 ****
--- 372,424 ----
and these flags have no effect after any system header file has been included.
+ @node gettextize and autopoint
+ @section Caveat: @code{gettextize} and @code{autopoint} users
+
+ @cindex gettextize, caveat
+ @cindex autopoint, caveat
+ The programs @code{gettextize} and @code{autopoint}, part of
+ GNU @code{gettext}, import or update the internationalization infrastructure.
+ Some of this infrastructure, namely ca.@: 20 autoconf macro files and the
+ @file{config.rpath} file, is also contained in Gnulib and may be imported
+ by @code{gnulib-tool}. The use of @code{gettextize} or @code{autopoint}
+ will therefore overwrite some of the files that @code{gnulib-tool} has
+ imported, and vice versa.
+
+ Avoiding to use @code{gettextize} (manually, as package maintainer) or
+ @code{autopoint} (as part of a script like @code{autoreconf} or
+ @code{autogen.sh}) is not the solution: These programs also import the
+ infrastructure in the @file{po/} and optionally in the @file{intl/} directory.
+
+ The copies of the conflicting files in Gnulib are more up-to-date than
+ the copies brought in by @code{gettextize} and @code{autopoint}. When a
+ new @code{gettext} release is made, the copies of the files in Gnulib will
+ be updated immediately.
+
+ The solution is therefore:
+
+ @enumerate
+ @item
+ When you run @code{gettextize}, always use the @code{gettextize} from the
+ newest GNU gettext release found on @url{http://ftp.gnu.org/gnu/gettext/},
+ and invoke @code{gnulib-tool} afterwards.
+
+ @item
+ When a script of yours run @code{autopoint}, invoke @code{gnulib-tool}
+ afterwards.
+
+ @item
+ If you get an error message like
+ @code{*** 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 @file{po/} infrastructure.
+ In this case, fetch and install the new GNU gettext release and run
+ @code{gettextize} followed by @code{gnulib-tool}.
+ @end enumerate
+
+
@node Localization
@section Handling Gnulib's own message translations
