Tweaking autotools-based buildsystem for W32 compatibility

[Kevin Stange]

On 04/25/2014 09:07 AM, LRN wrote:
> On 25.04.2014 17:52, Ethan Blanton wrote:
>> LRN spake unto us the following wisdom:
>>> On 25.04.2014 17:17, Ethan Blanton wrote:
>>>>>
>>>>> -libjabber_la_LDFLAGS = @PLUGIN_LDFLAGS@ +libjabber_la_LDFLAGS =
>>>>> -no-undefined
>>>>
>>>> This seems bogus to me.  What's the deal?
>>>
>>> PLUGIN_LDFLAGS resolves into "-no-undefined -avoid-version" This changes
>>> it to just "-no-undefined", because i like versioned shared libraries.
> 
>> OK.  If we want to make this change (which I do not think we do; if we
>> want to version plugins we probably want to do it differently), it needs
>> to be by way of changing PLUGIN_LDFLAGS, not hard-coding linker options in
>> the various Makefile.am files.
> 
> libjabber, libymsg and liboscar are not plugins, they are libraries
> (in this context plugin - shlib that exports one function, gets loaded
> explicitly; library - shlib that exports lots of stuff, gets linked to
> implicitly). Plugins shouldn't be versioned. Libraries should be.

I think that calling these formal libraries is generous.  These are
simply a way to allow shared code between protocol plugins that some
years ago were a single plugin hacked to add multiple entries to the
protocol list.

These separate libraries exist because the functionality doesn't need to
be in libpurple's API if you aren't building one of the plugins that
uses it, and statically linking them into each plugin doesn't really
seem logical.  There is never any reason anyone should link to them
other than internal plugins, and those should know exactly what they're
shipping with.

If there is functionality in these that we do want to expose, such as
the ability to directly interact and override XMPP behavior, we should
probably add to the protocol API accordingly.

With Ankit's gplugin-based code merged, these might actually be able to
go away, because a single plugin would be able to register multiple
protocols, I believe.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <https://pidgin.im/pipermail/devel/attachments/20140425/2c2cbd20/attachment.sig>