[PATCH 0/2] Simple fixes for run.in
The ./run script is a very useful way to run the libguestfs and virt-v2v test suites against a locally compiled copy of libvirt. These two patches contain some minor fixes. Rich.
This has been used in libguestfs and libnbd for quite a while as it makes the ./run script easier to read and write. See also: http://stackoverflow.com/a/9631350 Signed-off-by: Richard W.M. Jones <rjones@redhat.com> --- run.in | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/run.in b/run.in index 8574f81463..3118f9a9a4 100644 --- a/run.in +++ b/run.in @@ -42,22 +42,20 @@ # #---------------------------------------------------------------------- +# Function to intelligently prepend a path to an environment variable. +# See http://stackoverflow.com/a/9631350 +prepend() +{ + eval $1="$2\${$1:+:\$$1}" +} + # Find this script. b=@abs_builddir@ -library_path="$b/src/.libs" -if [ -z "$LD_LIBRARY_PATH" ]; then - LD_LIBRARY_PATH=$library_path -else - LD_LIBRARY_PATH="$library_path:$LD_LIBRARY_PATH" -fi +prepend LD_LIBRARY_PATH "$b/src/.libs" export LD_LIBRARY_PATH -if [ -z "$PKG_CONFIG_PATH" ]; then - PKG_CONFIG_PATH="$b/src" -else - PKG_CONFIG_PATH="$b/src:$PKG_CONFIG_PATH" -fi +prepend PKG_CONFIG_PATH "$b/src" export PKG_CONFIG_PATH # Ensure that any 3rd party apps using libvirt.so from the build tree get -- 2.24.1
On Thu, Jan 16, 2020 at 05:15:41PM +0000, Richard W.M. Jones wrote:
This has been used in libguestfs and libnbd for quite a while as it makes the ./run script easier to read and write.
See also: http://stackoverflow.com/a/9631350
Very neat, thanks for linking the stackoverflow article :). Reviewed-by: Erik Skultety <eskultet@redhat.com>
On Thu, Jan 16, 2020 at 05:15:41PM +0000, Richard W.M. Jones wrote:
This has been used in libguestfs and libnbd for quite a while as it makes the ./run script easier to read and write.
See also: http://stackoverflow.com/a/9631350
Signed-off-by: Richard W.M. Jones <rjones@redhat.com> --- run.in | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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> --- run.in | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/run.in b/run.in index 3118f9a9a4..d508e64802 100644 --- 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. -- 2.24.1
On Thu, Jan 16, 2020 at 05:15:42PM +0000, Richard W.M. Jones wrote:
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>
Since this patch doesn't break the original behaviour/use case I don't see a reason why we couldn't tweak PATH, you can have my: Reviewed-by: Erik Skultety <eskultet@redhat.com> ...but I'd wait a little before merging this patch if anyone with more expertise has further comments.
On Thu, Jan 16, 2020 at 05:15:42PM +0000, Richard W.M. Jones wrote:
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> --- run.in | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (3)
-
Daniel P. Berrangé -
Erik Skultety -
Richard W.M. Jones