Paul Eggert wrote:
> 2006-08-25 Paul Eggert <[EMAIL PROTECTED]>
>
> New configmake module, so that "make" output needn't be cluttered
> by fluff like '-DLIBDIR=\"/usr/local/lib\"'.
> * modules/configmake: New file.
IMO it would be useful to add comments that tell:
- Why does the module go through 'make', rather than using AC_DEFINE or
AC_DEFINE_UNQUOTED ? It is a little cumbersome, but possible to get
$(prefix) etc. directly in configure. (See lib-prefix.m4.)
- What is the advantage of the configmake module, compared to
'-DLIBDIR=\"$(libdir)\"' ?
A proposal:
# This module retrieves the 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.
#
# The advantage of this module, compared to the classical approach to add
# -DLIBDIR=\"$(libdir)\" etc. to the AM_CPPFLAGS, is that it protects against
# the use of undefined variables: If, say, $(libdir) is not set in the
# Makefile, LIBDIR will not be defined by this module, and code using LIBDIR
# will give a compilation error.
> + echo '#define CONFIGMAKE_LIBDIR "$(libdir)"'; \
> + echo '#define CONFIGMAKE_LOCALEDIR "$(localedir)"'; \
What is the 'CONFIGMAKE_' prefix good for? You said "namespace collision".
The gettext documentation mentions LOCALEDIR for years; the localcharset
module uses LIBDIR; the gettext sources use LIBDIR, BISON_LOCALEDIR,
PROJECTSDIR; all without problems.
We don't call the variable ac_libdir inside configure, make_libdir in a
Makefile. The variables inside configure, inside a Makefile, and in C
are supposed to contain the same values (expect for the delimiters and
backslashing changes). Therefore I'm in favour of dropping the
'CONFIGMAKE_' prefix.
Bruno
