Fwd: Workaround for libpurple's lack of set_alias()
Evan Schoenberg, M.D.
evan at adium.im
Fri Jan 15 22:47:12 UTC 2010
Sent from the wrong email address originally, so it bounced.
Begin forwarded message:
> Date: January 15, 2010 4:43:20 PM CST
> To: Felipe Contreras <felipe.contreras at gmail.com>
> Cc: pidgin-devel <devel at pidgin.im>, adium-devel <devel at adium.im>, Will Thompson <will.thompson at collabora.co.uk>, Devid Antonio Filoni <devidfil at gmail.com>, Craig Harding <craigwharding at gmail.com>, Mark Doliner <mark at kingant.net>
> Subject: Re: Workaround for libpurple's lack of set_alias()
> On Jan 14, 2010, at 6:24 PM, Felipe Contreras wrote:
>> Then the prpl would have to export a set_alias() function (just like
>> msn_set_friendly_name()). In case you are wondering if multiple
>> plugins's definition of set_alias() would conflict: no; symbols are
>> loaded in the local name-space. For example, all plugins export
>> 'purple_init_plugin' safely.
> I believe this would break static compilation. When compiling statically, plugins don't export purple_init_plugin(); they export purple_init_##x##_plugin() where ##x## is the prpl name.
>> You might wonder: wouldn't it be better to just fix libpurple? And to
>> that my answer is: ha! I wouldn't hold my breath.
> This is counterproductive.
>> I'm attaching the
>> patch just in case somebody else succeeds in getting it accepted,
> This is highly productive.
>> perhaps by issuing a secret offering to the right god, or maybe by
>> nailing the time when developers are not feeling moody.
> This, too, is counterproductive.
> What you're doing in this email remains good for us all - driving development forward, offering fixes in one hand and potential workarounds in the other. I love that; thanks. I'd love not to have to read through the ire towards libpurple developers to get to it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel