run.in: Include tools directory on $PATH.

You normally want to run the locally compiled copy of virsh.  Trying
to run the installed version with the locally compiled library is a
recipe for problems with missing symbols and so on.  By adding tools
to the path we can ensure that (eg) the libguestfs test suite will use
compatible copies of the library and virsh.

Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

diff --git a/run.in b/run.in
index 3118f9a9a45b64db52952c15dbc0d66c7ee69e91..d508e64802059cb5ea3349718f1a108ff2198fe3 100644 (file)
--- a/run.in
+++ b/run.in
@@ -21,12 +21,10 @@
 # With this script you can run libvirt programs without needing to
 # install them first.  You just have to do for example:
 #
-#   ./run ./tools/virsh [args ...]
+#   ./run virsh [args ...]
 #
-# If you are already in the tools/ subdirectory, then the following
-# command will also work:
-#
-#   ../run ./virsh [...]
+# Note that this runs the locally compiled copy of virsh which
+# is usually want you want.
 #
 # You can also run the C programs under valgrind like this:
 #
@@ -38,7 +36,7 @@
 #
 # This also works with sudo (eg. if you need root access for libvirt):
 #
-#   sudo ./run ./tools/virsh list --all
+#   sudo ./run virsh list --all
 #
 #----------------------------------------------------------------------
 
@@ -58,6 +56,9 @@ export LD_LIBRARY_PATH
 prepend PKG_CONFIG_PATH "$b/src"
 export PKG_CONFIG_PATH
 
+prepend PATH "$b/tools"
+export PATH
+
 # Ensure that any 3rd party apps using libvirt.so from the build tree get
 # files resolved to the build/source tree too. Typically useful for language
 # bindings running tests against non-installed libvirt.