Meson doesn't use .libs directory, everything is placed directly into
directories where meson.build file is used.
In order to have working tests and running libvirt directly from GIT we
need to fix all the paths pointing '.libs' directory.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
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>
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>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The Perl bindings for libvirt use the test driver for unit tests. This
tries to load the cpu_map/index.xml file, and when run from an
uninstalled build will fail.
The problem is that virFileActivateDirOverride is called by our various
binaries like libvirtd, virsh, but is not called when a 3rd party app
uses libvirt.so
To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be
set and make virInitialize look for this. The 'run' script will set it,
so now build using this script to run against an uninstalled tree we
will correctly resolve files to the source tree.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We're using virFileFindResourceFull() to locate resources
nowadays, which makes exporting these information in the
environment unnecessary: see
virDriverLoadModule() for LIBVIRT_DRIVER_DIR
virLockManagerPluginNew() for LIBVIRT_LOCK_MANAGER_PLUGIN_DIR
virLockManagerLockDaemonConnectionNew() for VIRTLOCKD_PATH
doRemoteOpen() for LIBVIRTD_PATH
As further proof that we don't need to expose the information
this way anymore, we're not even exporting VIRTLOGD_PATH, which
would be necessary if virLogManagerConnect() didn't already
take care of that for us.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It wasn't updated when libvirtd was moved from daemon/ to src/
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Allow people to build external bindings using the 'run' script
by defining the PKG_CONFIG_PATH var in it. eg to build Python
you could do
../libvirt/run python setup.py build
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the lock plugin use virFileFindResource to find the
virtlockd daemon path, so that it executes the in-builddir
daemon if run from source tree.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the remote driver use virFileFindResource to find the
libvirt daemon path, so that it executes the in-builddir
daemon if run from source tree.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The python binding now lives in
http://libvirt.org/git/?p=libvirt-python.git
that repo also provides an RPM which is upgrade compatible
with the old libvirt-python sub-RPM.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
It makes no sense to prohibit reuse of the wrapper in other LGPL
projects, since most of libvirt is designed to be LGPL. Of
course, when using the wrapper to wrap a GPL program, the combined
result is still effectively GPL, but that shouldn't force us to
license the wrapper as GPL in isolation.
* run.in: Relicense to LGPLv2+.
Nothing in run required bash, except for the shebang. On systems
where /bin/bash doesn't exist (I hit it on FreeBSD), using /bin/sh
instead fixes a 'make check' failure:
gmake[3]: Entering directory `/usr/home/dummy/libvirt/python'
GEN check-local
/usr/local/bin/bash: ../run: /bin/bash: bad interpreter: No such file or directory
* run.in: Use /bin/sh, not bash.
This adds a 'lockd' lock driver which is just a client which
talks to the lockd daemon to perform all locking. This will
be the default lock driver for any hypervisor which needs one.
* src/Makefile.am: Add lockd.so plugin
* src/locking/lock_driver_lockd.c: Lockd driver impl
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
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 ...]
If you are already in the tools/ subdirectory, then the following
command will also work:
../run ./virsh [...]
You can also run the C programs under valgrind like this:
./run valgrind [valgrind opts...] ./program
or under gdb:
./run gdb --args ./program
This also works with sudo (eg. if you need root access for libvirt):
sudo ./run ./tools/virsh list --all
Derived from libguestfs and simplified. The ./run script in
libguestfs is much more sophisticated:
https://github.com/libguestfs/libguestfs/blob/master/run.in
