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


More information about the Devel mailing list