changeset 14163:90cf49c6fdd5

document configmake in the manual instead of the source
author Karl Berry <karl@freefriends.org>
date Sun, 09 Jan 2011 16:30:27 -0800
parents aaf4bb6264c3
children dbe14b70ce13
files ChangeLog doc/configmake.texi doc/gnulib.texi modules/configmake
diffstat 4 files changed, 41 insertions(+), 15 deletions(-) [+]
line wrap: on
line diff
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-01-09  Karl Berry  <karl@gnu.org>
+
+	* doc/configmake.texi: New file.
+	* doc/gnulib.texi: Include it.
+	* modules/configmake: Move documentation from here.
+
 2011-01-09  Bruno Haible  <bruno@clisp.org>
 
 	Update to Unicode 6.0.0.
new file mode 100644
--- /dev/null
+++ b/doc/configmake.texi
@@ -0,0 +1,31 @@
+@node configmake
+@section configmake
+
+@findex configmake @r{module}
+@cindex @file{configmake.h}, module for updating
+
+The @code{configmake} module builds a C include file named
+@file{configmake.h} containing the usual installation directory
+values; for example, those specified by @code{--prefix} or
+@code{--libdir} to configure.  Each variable is given a @code{#define}
+with an all-uppercase macro name, such as @code{PREFIX} and
+@code{LIBDIR}.  (Automake cannot create this file directly because the
+user might override directory values at @code{make} time.)
+
+Specifically, the module retrieves values of the variables through
+@code{configure} followed by @code{make}, not directly through
+@code{configure}, so that a user who sets some of these variables
+consistently on the @code{make} command line gets correct results.
+
+One advantage of this approach, compared to the classical approach of
+adding @code{-DLIBDIR=\"$(libdir)\"} etc.@: to @code{AM_CPPFLAGS}, is
+that it protects against the use of undefined variables.  That is, if,
+say, @code{$(libdir)} is not set in the Makefile, @code{LIBDIR} is not
+defined by this module, and code using @code{LIBDIR} gives a
+compilation error.
+
+Another advantage is that @code{make} output is shorter.
+
+For the complete list of variables which are @code{#define}d this way,
+see the file @file{gnulib/modules/configmake}, or inspect your
+resulting gnulib Makefile.
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -6496,6 +6496,7 @@
 * Visual Studio Compatibility::
 * Supporting Relocation::
 * func::
+* configmake::
 * warnings::
 * manywarnings::
 * Running self-tests under valgrind::
@@ -6583,6 +6584,8 @@
 
 @include func.texi
 
+@include configmake.texi
+
 @include warnings.texi
 
 @include manywarnings.texi
--- a/modules/configmake
+++ b/modules/configmake
@@ -1,5 +1,5 @@
 Description:
-Variables set by "configure" or "make".
+Access from source code to variables set by "configure" or "make".
 
 Files:
 m4/configmake.m4
@@ -10,20 +10,6 @@
 gl_CONFIGMAKE_PREP
 
 Makefile.am:
-# Retrieve values of the variables through 'configure' followed by
-# 'make', not directly through 'configure', so that a user who
-# sets some of these variables consistently on the 'make' command
-# line gets correct results.
-#
-# One advantage of this approach, compared to the classical
-# approach of adding -DLIBDIR=\"$(libdir)\" etc. to AM_CPPFLAGS,
-# is that it protects against the use of undefined variables.
-# If, say, $(libdir) is not set in the Makefile, LIBDIR is not
-# defined by this module, and code using LIBDIR gives a
-# compilation error.
-#
-# Another advantage is that 'make' output is shorter.
-#
 # Listed in the same order as the GNU makefile conventions, and
 # provided by autoconf 2.59c+.
 # The Automake-defined pkg* macros are appended, in the order