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

Eric Blake eblake at redhat.com
Tue Mar 23 15:32:47 UTC 2010

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?

claimed that we need something here.  Looking at the gettext history,
here is what gettext used, prior to retiring usage of 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.
-  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

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 323 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100323/f9334204/attachment-0001.sig>

More information about the libvir-list mailing list