Workaround for libpurple's lack of set_alias()

[Felipe Contreras]

On Sat, Jan 16, 2010 at 12:43 AM, Evan Schoenberg, M.D.
<tekjew at gmail.com> wrote:
> 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.

Indeed, I thought about that right after I sent my mail.

Perhaps a PURPLE_MODULE_EXPORT macro would make sense, when the plugin
is static:
void ##x##_set_alias
otherwise
G_MODULE_EXPORT void set_alias

Again, I'm not really proposing this macro for libpurple, but rather
to prpls/clients that want to workaround this (like msn-pecan and
Adium).

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

See the last comment.

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

Ditto.

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

Thank you.

And sorry, if you are interested in my reply to your comments
regarding my cynical commentary, please let me know and I'll send you
a private reply. I'm trying to keep them minimal here.

Cheers.

-- 
Felipe Contreras