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.gz, 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@xxxxxxxxxxxxx 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list