reassign 370282 libglib2.0-dev
thanks
Loïc Minier <[EMAIL PROTECTED]> writes:
> In short, old autoconf:
> --prefix=PREFIX install architecture-independent files in PREFIX
> --datadir=DIR read-only architecture-independent data
> [PREFIX/share]
>
> new autoconf:
> --prefix=PREFIX install architecture-independent files in PREFIX
> --datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
> --datadir=DIR read-only architecture-independent data
> [DATAROOTDIR]
>
> The problem is in AM_GLIB_DEFINE_LOCALEDIR from
> m4macros/glib-gettext.m4 which hardcodes a double shell expansion:
> localedir=`eval echo "${datadir}/locale"`
>
> this results in a config.h with:
> #define GNOMELOCALEDIR "${prefix}/share/locale"
> which will obviously break at runtime.
>
> I verified that adding another level of expansion:
> localedir=`eval echo "${localedir}"`
> fixes the problem.
This simple stopgap measure will fix the immediate problem, but
it seems to me that the real problem with
AM_GLIB_DEFINE_LOCALEDIR is ignoring the instructions in the
Autoconf documentation. I've put an excerpt from the
documentation at the end of this mail for clarification.
So, if I understand the purpose here correctly, it's really a bug
in AM_GLIB_DEFINE_LOCALEDIR. I'm reassigning (with this mail)
the bug to libglib2.0-dev, which is the Debian package that
contains glib-gettext.m4.
> I doubt you will want to revert that autoconf change, and I don't know
> whether other macros are affected by this change, but I thought the bug
> tracker should see this bug. In the end, you might want to document
> this incompatibility in some upgrading documentation.
It might be a good idea to mention it in NEWS just because Gnome
is such popular software. I will suggest it to upstream.
> I've reported the problem of the AM_GLIB_DEFINE_LOCALEDIR macro at:
> <http://bugzilla.gnome.org/show_bug.cgi?id=343825>
> feel free to subscribe upstream to follow the discussion.
I'm unlikely to subscribe but I'll add the information from this
mail there.
> Right now, all I can think of to workaround the problem is to add
> another level of expansion in all cases in the macro, or to pass
> at least datarootdir or datadir to configure flags. I would be glad if
> you can provide some help in handling this large breakage though.
Here is what the manual says, as promised:
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/>.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
