[libvirt] [libvirt-glib] Correct namespace prefix for GVirConfig symbols

Daniel P. Berrange berrange at redhat.com
Tue Jan 3 14:31:49 UTC 2012


On Thu, Dec 22, 2011 at 04:17:32PM +0100, Christophe Fergeau wrote:
> On Thu, Dec 22, 2011 at 02:26:48AM +0200, Zeeshan Ali (Khattak) wrote:
> > On Thu, Dec 22, 2011 at 1:46 AM, Zeeshan Ali (Khattak)
> > <zeeshanak at gnome.org> wrote:
> > > On Thu, Dec 22, 2011 at 1:43 AM, Zeeshan Ali (Khattak)
> > > <zeeshanak at gnome.org> wrote:
> > >> From: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
> > >>
> > >> Breaks API and ABI on the fundamental level but lets fix this now while
> > >> we don't guarantee any API/ABI stability.
> > >
> > > Forgot to mention that this patch is on top of Christophe's ACK'ed but
> > > unmerged 'Add GVirConfigDomainSound' tree.
> > 
> >   And seems my patch went over the limit so it got chopped. You can
> > find the patch here as well:
> > https://gitorious.org/~zeenix/libvirt/zeenix-libvirt-glib/commit/d5e5c64732baa091d5078c87aab64df4cdb9e08d
> 
> For what it's worth, I don't think this patch improves the situation much
> if we can't express nested namespaces (ie put all the GVirConfigDomain*
> objects to a GVir::Config::Domain or GVirConfig::Domain namespace). Since
> it's pretty invasive, I'd lean toward not applying it, but I have no strong
> opinion either way, I'm fine if it goes in too. Let's see what danpb thinks
> about it :)

AFAICT, at the C level this is pretty much a no-op in terms of changes,
just changing naming conventions for types. What is the actual effect
on non-C language bindings that makes this compelling to change ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list