Workaround for libpurple's lack of set_alias()

[Felipe Contreras]

On Sat, Jan 16, 2010 at 3:57 PM, Felipe Contreras
<felipe.contreras at gmail.com> wrote:
> 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

This is more like it:

#ifndef STATIC
#define PURPLE_MODULE_EXPORT G_MODULE_EXPORT
#define PURPLE_MODULE_NAME(module, x) x
#else
#define PURPLE_MODULE_EXPORT
#define PURPLE_MODULE_NAME(module, x) module ## _ ## x
#endif

Which gets implemented like this:

PURPLE_MODULE_EXPORT void
PURPLE_MODULE_NAME(msn_pecan, set_alias) (PurpleConnection *gc,
                                          const gchar *value)
{
    /* implementation */
}

FTR. Already pushed this in msn-pecan.

Cheers.

-- 
Felipe Contreras