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

[Zeeshan Ali (Khattak)]

On Tue, Jan 3, 2012 at 4:31 PM, Daniel P. Berrange <berrange at redhat.com> 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 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 ?

  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