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 <ku...@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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel