bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnulib and gettext conflicts?


From: Bruno Haible
Subject: Re: Gnulib and gettext conflicts?
Date: Sun, 23 Mar 2008 20:15:41 +0100
User-agent: KMail/1.5.4

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  <address@hidden>

        * 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
  





reply via email to

[Prev in Thread] Current Thread [Next in Thread]