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

Nick Treleaven nick.treleaven at xxxxx
Thu Nov 25 17:07:00 UTC 2010


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().

> > I would probably accept a patch for a runtime check of Geany's API
> > number. I'm not sure how it would be useful ATM.
> 
> Urm, PLUGIN_VERSION_CHECK() generates a function that is a runtime
> check doesn't it??

It generates a function that returns the API required by the plugin. If
it is above Geany's API provided, then Geany won't load it.

I meant a function plugins could call at any time to ask for Geany's
API number, but maybe it wouldn't be useful anyway.

> 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.

Nick



More information about the Devel mailing list