maint: update copyright

[gnulib.git] / doc / gnulib-tool.texi

diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 7581d81..1b021a4 100644 (file)
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -1,7 +1,7 @@
 @node Invoking gnulib-tool
 @chapter Invoking gnulib-tool
 
 @node Invoking gnulib-tool
 @chapter Invoking gnulib-tool
 

-@c Copyright (C) 2005-2011 Free Software Foundation, Inc.
+@c Copyright (C) 2005-2014 Free Software Foundation, Inc.

 
 @c Permission is granted to copy, distribute and/or modify this document
 @c under the terms of the GNU Free Documentation License, Version 1.3 or
 
 @c Permission is granted to copy, distribute and/or modify this document
 @c under the terms of the GNU Free Documentation License, Version 1.3 or


@@ -217,6 +217,17 @@ gl_EARLY
 ...
 @end example
 
 ...
 @end example
 

+If you are using @code{AC_PROG_CC_STDC}, the macro @code{gl_EARLY} must
+be called after it, like this:
+
+@example
+...
+AC_PROG_CC
+AC_PROG_CC_STDC
+gl_EARLY
+...
+@end example
+

 The core part of the gnulib checks are done by the macro
 @code{gl_INIT}.  Place it further down in the file, typically where
 you normally check for header files or functions.  It must come after
 The core part of the gnulib checks are done by the macro
 @code{gl_INIT}.  Place it further down in the file, typically where
 you normally check for header files or functions.  It must come after


@@ -460,7 +471,9 @@ 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.
 
 new @code{gettext} release is made, the copies of the files in Gnulib will
 be updated immediately.
 

-The solution is therefore:
+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:

 
 @enumerate
 @item
 
 @enumerate
 @item


@@ -468,12 +481,13 @@ When you run @code{gettextize}, always use the @code{gettextize} from the
 matching GNU gettext release.  For the most recent Gnulib checkout, this is
 the newest release found on @url{http://ftp.gnu.org/gnu/gettext/}.  For an
 older Gnulib snapshot, it is the release that was the most recent release
 matching GNU gettext release.  For the most recent Gnulib checkout, this is
 the newest release found on @url{http://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.  Then, after @code{gettextize},
-invoke @code{gnulib-tool}.
+at the time the Gnulib snapshot was taken.

 
 @item
 
 @item

-When a script of yours run @code{autopoint}, invoke @code{gnulib-tool}
-afterwards.
+After running @code{gettextize}, invoke @code{gnulib-tool} and import
+the @code{gettext} module.  Also, copy the latest version of gnulib's
+@file{build-aux/po/Makefile.in.in} to your @file{po/} directory (this
+is done for you if you use gnulib's @file{bootstrap} script).

 
 @item
 If you get an error message like
 
 @item
 If you get an error message like


@@ -484,6 +498,32 @@ 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}.
 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
+
+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:
+
+@enumerate
+@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).
+
+@item
+Invoke @code{gnulib-tool}, and import the @code{gettext-h} module.
+@end enumerate
+
+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 @file{bootstrap} script follows these rules):
+
+@enumerate
+@item
+When a script of yours run @code{autopoint}, invoke @code{gnulib-tool}
+afterwards.

 
 @item
 When you invoke @code{autoreconf} after @code{gnulib-tool}, make sure to
 
 @item
 When you invoke @code{autoreconf} after @code{gnulib-tool}, make sure to


@@ -537,8 +577,8 @@ When you use these options, the functions in Gnulib are built
 in such a way that they will always use this domain regardless of the
 default domain set by @code{textdomain}.
 
 in such a way that they will always use this domain regardless of the
 default domain set by @code{textdomain}.
 

-In order to use this method, you must -- in each program that might use
-Gnulib code -- add an extra line to the part of the program that
+In order to use this method, you must---in each program that might use
+Gnulib code---add an extra line to the part of the program that

 initializes locale-dependent behavior.  Where you would normally write
 something like:
 
 initializes locale-dependent behavior.  Where you would normally write
 something like:
 


@@ -591,14 +631,14 @@ In projects which commit all source files, whether generated or not,
 into their VCS, the @code{gnulib-tool} generated files should all be
 committed.  In this case, you should pass the option
 @samp{--no-vc-files} to @code{gnulib-tool}, which avoids alteration of
 into their VCS, the @code{gnulib-tool} generated files should all be
 committed.  In this case, you should pass the option
 @samp{--no-vc-files} to @code{gnulib-tool}, which avoids alteration of

-VCS-related files such as @file{.cvsignore}.
+VCS-related files such as @file{.gitignore}.

 
 Gnulib also contains files generated by @command{make} (and removed by
 @code{make clean}), using information determined by
 @command{configure}.  For a Gnulib source file of the form
 @file{lib/foo.in.h}, the corresponding @file{lib/foo.h} is such a
 @command{make}-generated file.  These should @emph{not} be checked
 
 Gnulib also contains files generated by @command{make} (and removed by
 @code{make clean}), using information determined by
 @command{configure}.  For a Gnulib source file of the form
 @file{lib/foo.in.h}, the corresponding @file{lib/foo.h} is such a
 @command{make}-generated file.  These should @emph{not} be checked

-into the VCS, but instead added to @file{.cvsignore} or equivalent.
+into the VCS, but instead added to @file{.gitignore} or equivalent.

 
 @item
 In projects which customarily omit from their VCS all files that are
 
 @item
 In projects which customarily omit from their VCS all files that are


@@ -740,7 +780,7 @@ where the system's @code{timegm} function is missing or buggy, a replacement
 that is based on a function @code{mktime_internal}.  The module
 @code{mktime-internal} that provides this function provides it on all
 platforms.  So, by default, the file @file{mktime-internal.c} will be
 that is based on a function @code{mktime_internal}.  The module
 @code{mktime-internal} that provides this function provides it on all
 platforms.  So, by default, the file @file{mktime-internal.c} will be

-compiled on all platforms --- even on glibc and BSD systems which have a
+compiled on all platforms, even on glibc and BSD systems which have a

 working @code{timegm} function.  When the option
 @samp{--conditional-dependencies} is given, on the other hand, and if
 @code{mktime-internal} was not explicitly required on the command line,
 working @code{timegm} function.  When the option
 @samp{--conditional-dependencies} is given, on the other hand, and if
 @code{mktime-internal} was not explicitly required on the command line,