On 04/21/2010 10:01 AM, Chris Lalancette wrote:
> Add the library entry point for the new virDomainQemuMonitorCommand()
> entry point.  Because this is not part of the "normal" libvirt API,
> it gets it's own header file, library file, and will eventually
> get it's own over-the-wire protocol later in the series.

Now we get into the realm of multiple .so in a single package, at which
point switching over to the libtool versioning scheme makes more sense.
 In other words, it is now _very_ feasible that libvirt.so will change
versions between libvirt 0.8.1 and 0.8.2, while libvirt-qemu.so stays
stable between those two package releases.

We need to revisit this thread:
https://www.redhat.com/archives/libvir-list/2010-April/msg00226.html

> +++ b/src/Makefile.am
> @@ -32,7 +32,7 @@ if WITH_NETWORK
>  UUID=$(shell uuidgen 2>/dev/null)
>  endif
>  
> -lib_LTLIBRARIES = libvirt.la
> +lib_LTLIBRARIES = libvirt.la libvirt-qemu.la
>  
>  moddir = $(libdir)/libvirt/drivers
>  mod_LTLIBRARIES =
> @@ -947,6 +947,12 @@ libvirt_test_la_LIBADD = $(libvirt_la_LIBADD)
>  libvirt_test_la_LDFLAGS = $(test_LDFLAGS)
>  libvirt_test_la_CFLAGS = $(COVERAGE_CFLAGS)
>  
> +libvirt_qemu_la_SOURCES = libvirt-qemu.c
> +libvirt_qemu_la_LDFLAGS = $(CYGWIN_EXTRA_LDFLAGS) $(MINGW_EXTRA_LDFLAGS)

Shouldn't there be a -version-info $(...) as part of the LDFLAGS, since
this is a public rather than a convenience library?  Which gets back to
the question of whether $(LIBVIRT_VERSION_INFO) is the right thing to use.

> +libvirt_qemu_la_CFLAGS = $(COVERAGE_CFLAGS)
> +libvirt_qemu_la_LIBADD = libvirt_util.la libvirt_driver_qemu.la \
> +                     libvirt_driver_remote.la $(CYGWIN_EXTRA_LIBADD) \
> +                     ../gnulib/lib/libgnu.la

I still haven't had a successful attempt of building libvirt on cygwin;
I'm wondering if we have some cruft with all that
$(CYGWIN_EXTRA_LDFLAGS), but that is independent of this patch.

> +
> +int
> +virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd,
> +                            char **result, unsigned int flags)
> +{
> +    virConnectPtr conn;
> +
> +    DEBUG("domain=%p, cmd=%s, result=%p, flags=%u", domain, cmd, result, 
> flags);

Should we add a use of virCheckFlags here, to reject unknown flags?

-- 
Eric Blake   ebl...@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to