Tweaking autotools-based buildsystem for W32 compatibility

Tomasz Wasilczyk twasilczyk at
Fri Apr 25 08:44:23 EDT 2014

On 04/24/2014 11:59 PM, LRN wrote:
> On 25.04.2014 1:21, Tomasz Wasilczyk wrote:
>> 0058-rename-pidgin-to-pidgin3.all.patch: I don't think there is a need for
>> such rename. But I may be wrong. And possibly it might be useful to rename
>> libpurple to libpurple3.
> You might want to ask package maintainers. They often need things like this.

As we discussed on devel MUC, we might want to rename libpurple to 
libpurple3, but not necessarily the binaries.

I'm not sure about libpidgin and libfinch. These two were added in 3.0.0 
for various reasons (gobjectification? linking plugins?). I think they 
should be renamed to lib*3 too.

>> 0069-versioned-protolibs.mingw.patch: I don't think there is any gain from
>> versioning "base" protocol plugins.
> My position is simple: any re-usable library should have version numbers.
> Unlike protocol plugins (which just export one function for Pidgin to call),
> libjabber, liboscar and libymsg do export functionality, and it's no
> inconceivable for stuff to link to them. Also, on W32 they're in bin subdir,
> and unversioned stuff in bin irks me :)

I'm not sure we want to consider those libs as our exported interface. 
Maybe adding libjabber (I don't like this outdated name) to our API 
would be a good idea, but we'd need more work on this:
- make sure its API is fine
- make sure we won't break it in the future by adding any features
- gobjectify and gtkdoc-comment it

Until then, I'd recognize libjabber as a private lib, not exporting any 
functionality to the world.

About liboscar and libymsg: I don't think any other protocol is based on 
these, so there is no need to push it to the public API.

>> And few patches related to FHS, I'm working on right now:

Just for the record: it's already done.

>> DONT_USE_NICE_PNG_ICON_AS_DEFAULT - I'm not sure if we need this. I think
>> .ico files are enough for win32.
> I'm not sure either, but the comment said something about nice PNG icons, and
> i like PNG. If i get some extra free time, maybe i'll check what exactly this
> code does, and why was it disabled on W32.

I think win32 doesn't need this, because it has ico file loaded from .rc 
files, which are obviously missing from linux. And possibly early win32 
glib versions didn't supported it.

>> A request for other devs: please express your opinion, especially about
>> 0021, 0058, 0069, 0024, 0060 and 0029 (the patches I'm not sure about).
> I think you forgot that patches 0064-0069 were sent to you directly, they are
> not on the ML.

Right. I'm attaching 0069, the rest of them is already committed or was 
fixed by myself.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0069-versioned-protolibs.mingw.patch
Type: text/x-patch
Size: 1456 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4225 bytes
Desc: Kryptograficzna sygnatura S/MIME
URL: <>

More information about the Devel mailing list