[libvirt] [PATCH] Don't mix relative and absolute paths.

[Philipp Hahn]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100323/0ef9add4/attachment-0001.sig>