Avoid loading all the plugins

[Ludovico Cavedon]

Etan Reisner wrote:
> On Tue, Mar 24, 2009 at 01:46:26PM -0700, Ludovico Cavedon wrote:
>> Etan Reisner wrote:
> <snip>
>>> 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.

Well, yes. But maybe you can get the benefit of both :)

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

I see. Would be a patch in this direction welcome? I.e. an optional call
to libpurple that would wither disable calling of purple_plugins_probe()
or prevent the default library path to be added to the search paths?

> 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 aer
> guess-the-installed-plugins game.

Mhm, this is really a hack, but could work for as a workarund (don't
worry, just temporarily :)

>> http://developer.pidgin.im/ticket/8758
>> http://developer.pidgin.im/ticket/8758
> 
> Bugs like this should be fixed rather than worked around. I do, however,
> see your point.

I agree. In fact I took the time to track down the problem and provide a
patch/fix for both.

Thank you,
Ludovico