[Geany-devel] geany-plugins depends on GIO

[Lex Trotman]

>> Agree.  But also "in which version did the functions parameters and/or
>> semantics change" is more important.  If that change is newer than the
>> plugin then the plugin shouldn't try to run.
> I think that a simple update of the API version for this function is
> good enough for this. And anyway, I think that the current API scheme of
> Geany doesn't allow such changes without a function rename, so it would
> probably never happen, would it?

Change of parameters probably should cause a rename, change of
semantics (could be a bugfix) doesn't.

>
>> This would make
>>> easier for plugin developers to know for which version check.
>>> Also, perhaps a compile-time check would be interesting, it would allow
>>> things like "if Geany version is too old for this, it's not fatal, we
>>> will do without" -- stop me if it already exists.
>>
>> The plugin only depends on the ABI it wants to use, so in a perfect
>> world it would be able to check the each function it wants to call for
>> the version in which it last changed.  This will allow plugins to
>> continue to operate as long as possible without rebuilding.
>>
>> At initialisation the plugin could simply present a list of functions
>> and Geany could then return a list of versions for them (from a table
>> extracted from the doc comments).  It is then up to the plugin to
>> avoid functions it can't use, eg by not running at all or by limiting
>> functionality to avoid using functions that are too new, too old or
>> don't exist.
> I think this is probably overkill, and would make the plugin development
> really hard it it is a runtime check. Why? because you loose all the
> compile-time safety that tells us if we use an undefined symbol, if it
> isn't compatible and so on.

No, if you are compiling against an old Geany you can still remove the
code that uses newer features using #ifdefs and the statically defined
version of the ABI as you say below.

> It would need the plugin to something like "dynamically load Geany",
> while assuming that Geany has an unstable API. This is IMHO really
> complicated to deal with correctly, and I don't think that not having to
> recompile a plugin is a sufficient gain for such a pain.

Recompiling is not (much of?) a pain for us developers, but it is a
pain for other people who use Geany for non-C development.  They might
not even have a C development environment, especially on Windows.
Using Geany or plugins should not be dependent on being able to build
it.

The static version dependency means that either plugin development is
stalled if it needs newer API, or older versions of Geany are not
supported.

In fact even if no new features are used, a new geany_plugins release
will no longer run with an old version.

To support older versions of Geany, plugin devs need to maintain
multiple versions of their plugin and backport bugfixes, lotsa work
and doesn't fit into geany_plugins combined releases.  I'm not talking
about very old versions of Geany, the problem happens immediately at
release of a new version.  Geany maintains compatibility with
*ancient* versions of GTK, why then does it require itself to be the
latest version?

>
> I personally think that protecting code with something like
>  #if GEANY_CHECK_API_VERSION(421)
>  ...
>  #endif
> is enough.

Yes if you are compiling.

> Saying this makes me remember that Geany uses a macro for each function
> in the plugin API, so it is actually already possible to do a similar check:
>  #ifdef a_geany_function
>  ...
>  #endif
>
> Well... this gives lot of stuff to think about :D

Yes, isn't it past your bedtime again??

Cheers
Lex

>
> My 2 cents,
> Colomban
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>