Re: [Libguestfs] [PATCH 5/7] New APIs: add-domain and add-libvirt-dom.

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:

> 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.