Bug 1060966 Fix for Can't open perl script "/comm-central/mozilla/../build/win32/dumpenv4python.pl": No such file or directory r=glandium
authorIan Neal <iann_bugzilla@blueyonder.co.uk>
Wed, 08 Oct 2014 22:43:47 +0800
changeset 209353 d09b8e31e31912a590acbd55c76558d84a69a5f7
parent 209352 e0b3b8c184243a3e849d01bbac8b28eee35c0660
child 209354 6fc196832671632cc19fc08d5cbf1751fc5cbfad
push id1
push userroot
push dateMon, 20 Oct 2014 17:29:22 +0000
reviewersglandium
bugs1060966
milestone35.0a1
Bug 1060966 Fix for Can't open perl script "/comm-central/mozilla/../build/win32/dumpenv4python.pl": No such file or directory r=glandium
build/autoconf/hooks.m4
--- a/build/autoconf/hooks.m4
+++ b/build/autoconf/hooks.m4
@@ -42,17 +42,17 @@ define([AC_OUTPUT_SUBDIRS],
     if test ! -e "$_CONFIG_SHELL" -a -e "${_CONFIG_SHELL}.exe"; then
         _CONFIG_SHELL="${_CONFIG_SHELL}.exe"
     fi
     dnl Yes, this is horrible. But since msys doesn't preserve environment
     dnl variables and command line arguments as they are when transitioning
     dnl from msys (this script) to python (below), we have to resort to hacks,
     dnl storing the environment and command line arguments from a msys process
     dnl (perl), and reading it from python.
-    dumpenv="$PERL $srcdir/build/win32/dumpenv4python.pl $ac_configure_args | "
+    dumpenv="$PERL $_topsrcdir/build/win32/dumpenv4python.pl $ac_configure_args | "
     ;;
   esac
 
   eval $dumpenv $PYTHON $_topsrcdir/build/subconfigure.py --prepare "$srcdir" "$moz_config_dir" "$_CONFIG_SHELL" $ac_configure_args ifelse($2,,,--cache-file="$2")
 
   dnl Execute subconfigure, unless --no-recursion was passed to configure.
   if test "$no_recursion" != yes; then
     trap '' EXIT