On Tue, Jan 3, 2012 at 4:31 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > 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@xxxxxxxxx> wrote: >> > > On Thu, Dec 22, 2011 at 1:43 AM, Zeeshan Ali (Khattak) >> > > <zeeshanak@xxxxxxxxx> wrote: >> > >> From: "Zeeshan Ali (Khattak)" <zeeshanak@xxxxxxxxx> >> > >> >> > >> 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 ? I haven't really checked with other languages but vala tools get confused because we claim that GVirConfig is the namespace but then the macros aren't named accordingly. I can get you the exact errors I got from valac if you like but to me the problem is obvious and possible solutions are: 1. Use nested namespaces (not supported by GIR and based on past discussions about it, its unlikely GIR ever will). 2. Use same namespace 'GVir' (also not supported by GIR if we continue to have different gir/typelib files for each lib). 3. Continue using different namespaces for each lib and ensure all API is consistent with that approach. As it should be obvious now, #3 is the only viable solution here and hence my patch. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list