Am 09.07.2014 19:40, schrieb Matthew Brush:
On 14-07-09 10:01 AM, Dimitar Zhekov wrote:
On Tue, 08 Jul 2014 20:16:49 +0200 Thomas Martitz kugel@rockbox.org wrote:
My whole libpeas fork is (currently) imported into the geany repo so it's a bit academic.
I'd like to have a libpeas fork, or at least our own copy of the library (the code is actually quite small). The latest libpeas requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package even has gtk+3 as requirement because of libpeas-gtk, which is actually optional and will not be used in Geany.
You could use that point to recommend forking all of our dependencies, for example the latest GLib/GObject/GModule/GIO is >= 2.30 too, the latest GTK+ is 3.12 and requires GLib >= 2.39, the latest Pango requires GLib >= 2.32. We can't fork everything :)
IMO, it'd be better just to depend on an older version than the latest like we do for everything else, and maybe open a bug report for the Debian package if it wrongly makes libpeas depend on libpeas-gtk instead of the other way around.
If I understand correctly, libpeas backends are pluggable/modules that do not need to be hardcoded into core either, so there's no too much incentive to keep our own fork/modified copy for that purpose, IMO.
The fork is necessary (for now) for two reasons: * the code to detect current $plugin.so files as plugins and generate a PeasPluginInfo for them (in addition to those indicated by $plugin.plugin) has to be in libpeas core, PeasPluginInfo creation is not pluggable. * even though the actual loader is pluggable, the api (PeasPluginLoader interface) for that is private. there are no public headers which allow third-party loaders so the loader has to be build within libpeas
It's not a huge problem for now since libpeas isn't developed at a overwhelming pace currently (mostly because it's simply done).
Best regards.