Compiling libpurple with MS Visual C++ 2008 Express

[John Bailey]

Lee Roach wrote:
> I've seen several mailings on this list previously about compiling
> libpurple with a native win32 compiler and had to point out that it is
> in fact possible. I had been curious myself for quite a while, and have
> finally confirmed that it works. While this method could theoretically
> be used to build the entire pidgin sources, we lose a key benefit of
> using MSVC at all: debugging. Since we have no IDE debugging abilities,
> I see no reason to pursue this any further. Not to mention, we lose
> support for anything older than Windows 2000.

I've attempted to attract developers to a .NET native UI for Win32.  The project
is located at http://vulture.rekkanoryo.org/trac/ and Daniel Atallah provided
instructions and project files for building libpurple with Visual Studio .NET.
The .NET UI would most likely be Windows 2000 or later only, since one UI
approach requires .NET 2.0 and the other requires .NET 3.0.

> My original goal was to initially compile nullclient and dependencies,
> and then design a native UI on top of it.

Were you planning to use MFC or something from the .NET runtime stuff?
Personally I would prefer to see an MFC-based client, but I gave up on that hope
after the discussion that ensued on this list prior to the Summer of Code, where
it seemed that no one actually cares about backward compatibility on Windows.

> The main difficulty when compiling with an MSVC newer than 6.0 is that
> it doesn't supply the link libraries for the proper version of the C
> runtime library, and libpurple will break severely if it's compiled
> against anything other than msvcrt.lib/dll. Since all of libpurple's
> dependencies use msvcrt, we can't build it with msvcrt9 or whatever they
> call it today, and are forced to find a workaround. The workaround for
> building against the OS-supplied runtime instead of the Visual Studio
> supplied one is available in this blog [3], or a more condensed version
> in this blog [4].

Daniel has submitted a patch to Glib, which was accepted, to update their Visual
Studio .NET project files.  It's now possible, although not that well
documented, to build Glib with recent Visual Studio versions.  I did it a while
back; took a bit of finesse but it wasn't overly difficult if you're familiar
with building projects.

With Glib built, you can build libpurple with Visual Studio by following
Daniel's instructions here:
http://vulture.rekkanoryo.org/trac/browser/trunk/libpurple/vs8/instructions.txt

<snip>
> The libpurple sources should now build successfully, and the
> libpurple.dll that's output can be used as a drop-in replacement for the
> MinGW built one, and you can now sit back and have a beer, and realize
> you almost completely wasted your time.

Wasting time is what we do best, isn't it?

> After doing the above steps, I came to the realization that compiling a
> libpurple UI in MSVC would be better linked to a standard MinGW-built
> libpurple, even if we lose the ability to debug both UI and libpurple
> simultaneously. At least libpurple can still be debugged via gdb, and
> the UI can still be debugged via MSVC, which is better than not being
> able to debug either one. However, it's still not as good as compiling
> all of libpurple's dependencies in MSVC, but I don't think anyone has
> the time to do that properly, nor the desire.

I disagree.  I think building libpurple for win32 natively with Microsoft's
compilers will be better in the long term if a native UI actually appears.

> I hope I at least answered a few questions for those desiring a similar
> MSVC-built libpurple UI, and perhaps shed some light on why there is
> still little movement in this direction.

I think that for the most part, Pidgin is "good enough," and clients like
Miranda, Trillian, etc. exist, so few with the development skills care to invest
time in such a project.  Still, proving that we *can* interchangably build
libpurple with Visual Studio was a somewhat interesting endeavor.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080823/a0fad3e7/attachment.sig>