/soc/2013/ankitkv/gobjectification: 20188870cc4b: Bump the GPlug...

[Ankit Vani]

On 2 August 2013 12:05, Kevin Stange <kstange at pidgin.im> wrote:
> On 07/31/2013 02:35 PM, Ankit Vani wrote:
>>               AC_MSG_ERROR([
>> -     GPlugin 0.0.3 development headers not found, which are required if you wish
>> +     GPlugin 0.0.4 development headers not found, which are required if you wish
>>       to enable plugins.
>>       Use --disable-plugins if you do not need plugins.
>>       ])])
>
> I haven't really evaluated your changes to plugins in that much detail,
> but if GPlugin is unavailable, will prpls still work?  If not, libpurple
> becomes useless and thus this shouldn't be an optional dependency.
>
> Kevin

Hi Kevin

No, if GPlugin is not available then prpls will not work.

But it is not exactly an optional dependency if you enable plugins. Even before,
prpls would not be built if you had passed --disable-plugins (since it
completely disables the gmodule stuff).

I have retained that bit, and ensured that GPlugin is required if you are
building with plugins (which you probably will).

Also, I would like to note that there will be no such thing as a 'prpl' in the
new API. Plugins do not necessarily have to belong to any of the old types such
as 'protocol', 'loader', 'standard' etc. I haven't started working on the
protocol API yet (for now PurplePluginProtocolInfo in itself represents a
protocol), but plugins will be able to register and unregister protocols and do
other things too if necessary. Whether this is a good idea or not for a plugin,
it made sense to remove this restriction. :)

Ankit