Avoid loading all the plugins
pidgin at unreliablesource.net
Tue Mar 24 22:54:19 EDT 2009
On Tue, Mar 24, 2009 at 01:46:26PM -0700, Ludovico Cavedon wrote:
> Etan Reisner wrote:
> > Don't build or install the plugins you don't want/need, or build libpurple
> > with your plugins of choice compiled in statically and disable plugins.
> Yes, this is what qutecom is currently doing, but I would like to use
> the system libpurple library provided with Ubuntu/Debian, rather than
> having qutecom ship its own copy of libpurple.
Using the system libpurple has costs as well as benefits.
At the moment the only way around this that I can see is by means of a
rather ugly set of "hacks". That is, re-implementing a couple libpurple
functions to avoid the calls that cause the default plugins to be loaded
thereby allowing you to manually probe and load plugins of your choice.
I don't believe I see any other way of doing this more properly even with
support from libpurple unfortunately.
purple_core_init calls purple_plugins_init which sets up the default
libpurple plugin search path, purple_core_init then calls
purple_plugins_probe which uses the search path set up by
purple_plugins_init to search for (and probe/load) plugins.
Unfortunately, I can't see a good way to allow the UI to interject into
that process in a meaningful fashion.
It might be possible to ship your own stub plugins and add your own search
path before calling purple_core_init thereby causing your stubs to be
loaded instead of the default plugins. But that will only work for plugins
you specifically override, which involves you in a
> Ethan Blanton wrote:
> > Any purple core plugins which are installed with libpurple will be
> > loaded, and there's not currently anything you can do about that.
> > They won't hurt anything, though, so you can probably just ignore
> > them. Why do you believe they will pose a problem?
> There are two reasons:
> -reduce load time and memory used (why should I load libtcl and libperl
> when I am sure I will never user them?)
> -reduce the change of plugins making the application crash (currently
> happening with perl and tcl
> Thank you,
Bugs like this should be fixed rather than worked around. I do, however,
see your point.
More information about the Devel