[Geany-devel] geany-plugins depends on GIO - plugin API version checks

[Lex Trotman]

On 27 November 2010 23:46, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On Fri, 26 Nov 2010 07:06:12 +1100
> Lex Trotman <elextr at gmail.com> wrote:
>
>> On 26 November 2010 04:07, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>> > On Thu, 25 Nov 2010 10:54:07 +1100
>> > Lex Trotman <elextr at gmail.com> wrote:
>> >
>> >> On 24 November 2010 23:54, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>> >> > On Tue, 23 Nov 2010 09:09:59 +1100
>> >> > Lex Trotman <elextr at gmail.com> wrote:
>> >> >
>> >> >> But the general consensus seems to be that people are happy to use
>> >> >> static versioning and to keep conpiling (well it is the developer
>> >> >> list) and either manually checking what has changed in an API/ABI
>> >> >> break or (more probably) to hope that C's leaky type system catches
>> >> >> any problem.
>> >> >
>> >> > ABI checking is automatic, not manual (assuming the
>> >> > PLUGIN_VERSION_CHECK() macro is used and not manually implemented
>> >> > wrongly).
>> >>
>> >> What I meant was that if the version fails, my guess is that most
>> >> plugin devs just bump the version in their plugin and recompile and
>> >> hope that the compiler catches any incompatible changes.  Only the
>> >> really conscientious ones will check which functions changed and if it
>> >> affects their code.
>> >
>> > No, plugins should not have any ABI number constant in their source.
>> > See the source for PLUGIN_VERSION_CHECK().
>>
>> That checks that the version of geany loading the plugin matches the
>> version the plugin was compiled with.  It doesn't check that the
>> recompiled plugin works with the new ABI which is what I'm talking
>> about.  Only the compiler (if you are lucky) or manual checks can do
>> that.
>
> When we break the ABI we try to do it so the compiler would catch any
> problems - usually we would remove the old field name or function name.

I guess thats ok if you guarantee to never change the behavior of
anything, always adding a new function if you want modified behavior.

Probably needs to go in Hacking.

OTOH If we are sticking with the requirement to recompile then using:

#if GEANY_ABI_VERSION != xxx
#error Can't compile with this version of Geany, needs 0.99999.1
#endif

is a more user friendly error than some miscellaneous type error.

>
> (Plugin devs don't need to bump anything when the ABI changes.)

It has that advantage.

>
>> >> Don't you use:
>> >>
>> >> #if GEANY_ABI_VERSION != xxx /* or whatever conditions */
>> >> #error ABI mismatch
>> >> #endif
>> >>
>> >> for compile time check??
>> >
>> > There is no need to try to do that if plugins use the
>> > PLUGIN_VERSION_CHECK macro (which all should), and xxx would need to be
>> > read from Geany anyway, so that can't be done with the preprocessor.
>>
>> 1. PLUGIN_VERSION_CHECK is a runtime check, this is a compile time check
>>
>> 2. GEANY_ABI_VERSION and GEANY_API_VERSION *are* read from Geany, they
>> are in plugindata.h and as noted above there isn't a runtime way of
>> reading them.  The xxx is the version the plugin uses and has to be a
>> constant in the source.
>>
>> 3. GEANY_VERSION_CHECK requires GEANY_ABI_VERSION match what it was
>> compiled with, it can't check that its a version the plugin can use or
>> refuse to compile if it isn't.
>
> I think it's too complicated to have a plugin compatible with 2 or more
> ABIs. It's asking for trouble.

Hmmm, its a bit rude to say that plugin devs are not smart enough to write

#if GEANY_ABI_VERSION > xxx
// get the data I need the new way
#else
// get the data I need the old way
#endif

Cheers
Lex

>
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>