10:07 a.m.
autoconf goes to great lengths to calculate a proper MKINSTALLDIRS path,
so just export the variable for gettext, but don't overwrite it with a
broken path:
$(top_builddir) is a relative path, while $ac_aux_dir can be an absolute
path.
Signed-off-by: Philipp Hahn <hahn(a)univention.de>
---
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
10:32 a.m.
On 03/23/2010 09:07 AM, Philipp Hahn wrote:
autoconf goes to great lengths to calculate a proper MKINSTALLDIRS
path,
Actually, neither autoconf nor automake touches MKINSTALLDIRS; it is all
provided by gettext. Did you test with gettext 0.14, automake 1.9.6 and
autoconf 2.59?
so just export the variable for gettext, but don't overwrite it
with a
broken path:
$(top_builddir) is a relative path, while $ac_aux_dir can be an absolute
path.
That's a true statement. But doesn't automake/autoconf provide some
magic to make it track the correct number of ../ components to be
properly relative through subdirectories? In other words, what breakage
are you fixing?
https://www.redhat.com/archives/libvir-list/2010-February/msg00873.html
claimed that we need something here. Looking at the gettext history,
here is what gettext used, prior to retiring usage of MKINSTALLDIRS:
-AC_DEFUN([AM_MKINSTALLDIRS],
-[
- dnl Tell automake >= 1.10 to complain if mkinstalldirs is missing.
- m4_ifdef([AC_REQUIRE_AUX_FILE], [AC_REQUIRE_AUX_FILE([mkinstalldirs])])
- dnl If the AC_CONFIG_AUX_DIR macro for autoconf is used we possibly
- dnl find the mkinstalldirs script in another subdir but $(top_srcdir).
- dnl Try to locate it.
- MKINSTALLDIRS=
- if test -n "$ac_aux_dir"; then
- case "$ac_aux_dir" in
- /*) MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs" ;;
- *) MKINSTALLDIRS="\$(top_builddir)/$ac_aux_dir/mkinstalldirs" ;;
- esac
- fi
- if test -z "$MKINSTALLDIRS"; then
- MKINSTALLDIRS="\$(top_srcdir)/mkinstalldirs"
- fi
- AC_SUBST(MKINSTALLDIRS)
-])
Maybe the real fix for the problem you seem to be seeing is to repeat
more of the body of this (now-obsolete) gettext macro, in the case that
we are still targetting older gettext 0.14.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
11:16 a.m.
Hello,
Am Dienstag 23 März 2010 16:32:47 schrieben Sie:
On 03/23/2010 09:07 AM, Philipp Hahn wrote:
> autoconf goes to great lengths to calculate a proper MKINSTALLDIRS path,
Actually, neither autoconf nor automake touches MKINSTALLDIRS; it is all
provided by gettext. Did you test with gettext 0.14, automake 1.9.6 and
autoconf 2.59?
Just to give you some context: We at Univention build our own Linux Enterprise
Distribution based on Debian, so our source is basically the Debian source
plus some additional patches. We and Debian are using
http://ftp.debian.org/debian/pool/main/libv/libvirt/libvirt_0.7.7.orig.ta...,
which is the same as http://libvirt.org/sources/libvirt-0.7.7.tar.gz.
Since neither Debian nor we did re-run any auto*-stuff, we still use the
original "configure*" and Makefile*s.
If you take a look at configure as shipped, you'll file configure already
calculating MKINSTALLDIRS:
# tar xfzO libvirt_0.7.7.orig.tar.gz libvirt-0.7.7/configure | grep -A2 -B2
MKINSTALLDIRS=
...
if test -n "$ac_aux_dir"; then
case "$ac_aux_dir" in
/*) MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs" ;;
*) MKINSTALLDIRS="\$(top_builddir)/$ac_aux_dir/mkinstalldirs" ;;
esac
fi
if test -z "$MKINSTALLDIRS"; then
MKINSTALLDIRS="\$(top_srcdir)/mkinstalldirs"
fi
My build environment is somehow older and looks like
autoconf 2.61-8.13.200909072244
automake 1:1.10+nogfdl-1.5.200909151702
automake1.7 1.7.9-9.10.200909151713
gettext 0.17-4.17.200909090228
libtool 1.5.26-4.15.200909100942
> so just export the variable for gettext, but don't overwrite
it with a
> broken path:
> $(top_builddir) is a relative path, while $ac_aux_dir can be an absolute
> path.
That's a true statement. But doesn't automake/autoconf provide some
magic to make it track the correct number of ../ components to be
properly relative through subdirectories? In other words, what breakage
are you fixing?
Yes: top_builddir is relative, but ac_aux_dir can be an absolute path, if you
run "/absolute/path/to/configure" instead of "../../configure".
I currently need this, because I need to build the source multiple times for
different Python versions (2.4 and 2.5). The autoconf-stuff currently doesn't
support this, so I need to build the whole source out-of-tree three times
with different Python versions passed to --with-python=/usr/bin/python2.[45].
Using relative pathes there broke some other stuff, so I decided to use
absolute paths, which was working fine until I switched from 0.7.6 to 0.7.7.
https://www.redhat.com/archives/libvir-list/2010-February/msg00873.html
claimed that we need something here. Looking at the gettext history,
here is what gettext used, prior to retiring usage of MKINSTALLDIRS:
Yes, and here you see, that ac_aux_dir must be checked for being either
absolute or relative:
- case "$ac_aux_dir" in
- /*) MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs" ;;
- *) MKINSTALLDIRS="\$(top_builddir)/$ac_aux_dir/mkinstalldirs" ;;
The current code assumes relative paths all the time and unconditionally
prefixes ac_aux_dir with top_builddir, which is wrong.
Maybe the real fix for the problem you seem to be seeing is to
repeat
more of the body of this (now-obsolete) gettext macro, in the case that
we are still targetting older gettext 0.14.
Maybe you're right and yours is the better fix.
I just had a look at what's already in configure: Since MKINSTALLDIR was
already calculated correctly before being overwriten by that
AC_SUBST()-statement, I decided to just remove the false assignment.
BYtE
Philipp Hahn
--
Philipp Hahn Open Source Software Engineer hahn(a)univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de
5389
days inactive
5389
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Philipp Hahn