[Geany-devel] geany-plugins depends on GIO

[Colomban Wendling]

Le 18/11/2010 01:18, Lex Trotman a écrit :
> On 18 November 2010 10:16, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>> Le 17/11/2010 23:09, Lex Trotman a écrit :
>>> On 18 November 2010 03:36, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>>> But does new API really matters? If a plugin writer wants to keep being
>>>> compatible with old Geany versions, she just have not to use new API --
>>>> as far as the ABI hasn't changed.
>>>>
>>>
>>> But ATM how does a plugin check that without being re-compiled?
>> What what what? :D
>> If a plugin compiles with version 0.18 and Geany doesn't detect a
>> problem when comparing the ABI version it was built against, it IS
>> compatible, no? And if the same plugin is compiled against Geany 0.19
>> (assuming the ABI hasn't changed), it will still work with Geany 0.18...
> 
> Yes, but ANY change to the API/ABI even in areas that the plugin
> doesn't use changes the version and makes the plugin incompatible with
> older Geany.
Okay, I think I got your point, reading this and some other mails in
this thread: you want to prevent ABI bumps to break plugins that are not
directly affected.

Yes, an ABI bump break every plugin that was compiled before it. If it
isn't affected, it has to be rebuild.

But I'm with Enrico here: I don't think ABI bumps will/should happen often.

And finally, if you want to protect from ABI breakage, you have to
protect every symbol, not only functions, but also structures and
structure members (even enums values may need this then).

So... while I'm not (and never was) against having a very flexible
dependency mechanism, I still think it's overkill, and won't it to make
everything complicated. If backbard compatibility is this important, I'd
prefer to simply keep the whole ABI stable, even if it may cost some
deprecated things and some "old and now useless stuff": it isn't really
nice either, but still seems less bloated to me.

But I'd be curious to see how you would implement this :)


Regards,
Colomban