Re: [bug-gnulib] Re: proposed gnulib module 'configmake', plus use by 'localcharset'

[Bruno Haible]

Paul Eggert wrote:
> 2006-08-25  Paul Eggert  <address@hidden>
> 
>       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