1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-26 03:21:44 +03:00
Commit Graph

10 Commits

Author SHA1 Message Date
Daniel P. Berrange
78c09530ba Add PKG_CONFIG_PATH to run.in script.
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>
2014-06-26 14:32:35 +01:00
Daniel P. Berrange
e18a80a3a0 Use virFileFindResource to locate virtlockd daemon
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>
2014-04-28 13:30:41 +01:00
Daniel P. Berrange
57e5c3c2ae Use virFileFindResource to locate libvirtd daemon
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>
2014-04-28 13:30:41 +01:00
Daniel P. Berrange
a7a1244a73 Remove python binding
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>
2013-11-25 16:08:00 +00:00
Eric Blake
448c93cf98 run: license as LGPL
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+.
2013-02-23 14:03:19 -07:00
Eric Blake
2795813c69 run: use portable shell
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.
2013-02-22 17:16:12 -07:00
Daniel P. Berrange
eb8268a4f6 Add a virtlockd client as a lock driver impl
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>
2012-12-13 15:26:57 +00:00
Martin Kletzander
9ac287f826 syntax-check: fix run.in
Two more problems in "run.in" made the syntax-check fail.
2012-09-18 13:59:53 +02:00
Guido Günther
956ce7b472 Adhere to copyright_address check
to fix "make syntax-check"

Found by http://honk.sigxcpu.org:8001/job/libvirt-syntax-check/
2012-09-18 13:55:40 +02:00
Richard W.M. Jones
5090c576e3 Add a ./run script for running programs from the local directory.
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
2012-09-18 10:59:16 +01:00