On Wed, Nov 10, 2010 at 11:58:40AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 10, 2010 at 11:46:31AM +0000, Richard W.M. Jones wrote:
> diff --git a/src/guestfs.h b/src/guestfs.h
> index 0f4f9fd..be7398a 100644
> --- a/src/guestfs.h
> +++ b/src/guestfs.h
> @@ -79,6 +79,11 @@ extern void guestfs_set_private (guestfs_h *g, const char *key,
void *data);
> extern void *guestfs_get_private (guestfs_h *g, const char *key);
>
> /*--- Structures and actions ---*/
> +
> +/* Hack to avoid needing to include <libvirt.h> */
> +typedef struct _virDomain virDomain;
> +typedef virDomain *virDomainPtr;
> +
> #include <rpc/types.h>
> #include <rpc/xdr.h>
> #include <guestfs-structs.h>
Surely this will break any application whose code does
#include <libvirt/libvirt.h>
#include <guestfs.h>
because they'll get a duplicated definition of virDomain from
both headers.
I checked and it works fine both ways round. It would break if
libvirt changed the definition, but you've boxed yourself into a
corner there by documenting the current definition:
http://libvirt.org/html/libvirt-libvirt.html
IMHO, this hack is a waste of time and it is better to just
#include <libvirt/libvirt.h> from the header files instead.
The problem is libvirt would no longer be an optional dependency for
programmers using libguestfs.
A build time dependancy on the libvirt client is really not
a burden, when you consider that weight of the entire build
chain you already have to pull in. Even with the build time
dep, you can still have the dep be optional at runtime via
your use of dlopen().
In some quarters libvirt is not welcome and libguestfs doesn't depend
on libvirt being there, but will use it if available to provide
enhanced features.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog:
http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora