Workaround for libpurple's lack of set_alias()

[Evan Schoenberg, M.D.]

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.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20100115/0cd1d0f0/attachment-0001.html>