[libvirt] [PATCH] Don't mix relative and absolute paths.
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@univention.de> --- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
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.tar.g..., 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:
- 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
Yes, and here you see, that ac_aux_dir must be checked for being either absolute or relative: 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@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
participants (2)
-
Eric Blake -
Philipp Hahn