Your message dated Thu, 25 May 2006 07:08:03 -0700
with message-id <[EMAIL PROTECTED]>
and subject line closing: configure.in does not follow documentation guidelines
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: autoconf
Version: 2.59.cvs.2006.05.13-1
Severity: important

If configure.in uses ${datadir} for some reason this version of autoconf tries 
to replace it with ${datarootdir}, the variable 
doesn't get replaced (strace proves this).

Downgrading to version 2.59a-9 resolves this.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages autoconf depends on:
ii  debianutils                   2.16.1     Miscellaneous utilities specific t
ii  m4                            1.4.4-1    a macro processing language
ii  perl                          5.8.8-4    Larry Wall's Practical Extraction 

Versions of packages autoconf recommends:
ii  automake1.7 [automaken]       1.7.9-7    A tool for generating GNU Standard
ii  automake1.9 [automaken]       1.9.6-4    A tool for generating GNU Standard

-- no debconf information


--- End Message ---
--- Begin Message ---
As Ralf points out, the following code in the configure.in in
question does not follow the guidelines in the Autoconf
documentation.

| dnl Set PACKAGE_DATA_DIR in config.h.
| if test "x${datadir}" = 'x${prefix}/share'; then
|   if test "x${prefix}" = "xNONE"; then
|     AC_DEFINE_UNQUOTED(PACKAGE_DATA_DIR, 
"${ac_default_prefix}/share/${PACKAGE}", [Shared Data Directory] )
|   else
|     AC_DEFINE_UNQUOTED(PACKAGE_DATA_DIR, "${prefix}/share/${PACKAGE}", 
[Shared Data Directory])
|   fi
| else
|   AC_DEFINE_UNQUOTED(PACKAGE_DATA_DIR, "${datadir}/${PACKAGE}", [Shared Data 
Directory])
| fi

Here is the particular recommendation from the documentation that
this violates.  Because this is a bug in configure.in, not in
Autoconf, I am closing this bug.

How Do I `#define' Installation Directories?
============================================

     My program needs library files, installed in `datadir' and
     similar.  If I use
          AC_DEFINE_UNQUOTED([DATADIR], [$datadir],
                             [Define to the read-only architecture-independent
                              data directory.])
     
     
     I get
          #define DATADIR "${prefix}/share"

As already explained, this behavior is on purpose, mandated by the GNU
Coding Standards, see *Note Installation Directory Variables::.  There
are several means to achieve a similar goal:

   - Do not use `AC_DEFINE' but use your `Makefile' to pass the actual
     value of `datadir' via compilation flags, see *Note Installation
     Directory Variables::, for the details.

   - This solution can be simplified when compiling a program: you may
     either extend the `CPPFLAGS':

          CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@

     or create a dedicated header file:

          DISTCLEANFILES = datadir.h
          datadir.h: Makefile
                  echo '#define DATADIR "$(datadir)"' >$@

   - Use `AC_DEFINE' but have `configure' compute the literal value of
     `datadir' and others.  Many people have wrapped macros to automate
     this task.  For instance, the macro `AC_DEFINE_DIR' from the
     Autoconf Macro Archive(1).

     This solution does not conform to the GNU Coding Standards.

   - Note that all the previous solutions hard wire the absolute path to
     these directories in the executables, which is not a good
     property.  You may try to compute the paths relatively to
     `prefix', and try to find `prefix' at runtime, this way your
     package is relocatable.  Some macros are already available to
     address this issue: see `adl_COMPUTE_RELATIVE_PATHS' and
     `adl_COMPUTE_STANDARD_RELATIVE_PATHS' on the Autoconf Macro
     Archive(2).

   ---------- Footnotes ----------

   (1) Autoconf Macro Archive,
<http://www.gnu.org/software/ac-archive/>.

   (2) Autoconf Macro Archive,
<http://www.gnu.org/software/ac-archive/>.


-- 
"In this world that Hugh Heffner had made,
 he alone seemed forever bunnyless."
--John D. MacDonald

--- End Message ---

Reply via email to