Tweaking autotools-based buildsystem for W32 compatibility
Tomasz Wasilczyk
twasilczyk at pidgin.im
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.
Tomek
-------------- 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: <https://pidgin.im/pipermail/devel/attachments/20140425/c32eb9cc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4225 bytes
Desc: Kryptograficzna sygnatura S/MIME
URL: <https://pidgin.im/pipermail/devel/attachments/20140425/c32eb9cc/attachment-0001.bin>
More information about the Devel
mailing list