Compiling libpurple in Visual Studio

[David Byron]

On Monday, May 28, 2007 @ 2:47p, Nick Hebner wrote:

> > On 5/28/07, David Byron <dbyron at dbyron.com> wrote:
> 
> > I don't see either of these files in the root of the
> > pidgin-2.0.1 tarball.  I do see a version.h in the libpurple
> > directory and config.h.mingw in the root.  Are those the
> > files you mean?
> 
> Yes, you are right. I think that config.h.mingw gets copied
> to config.h during the mingw compile.

I'll dive into this more if I can pull off what I write below, but does
mingw really need its own hard coded config.h?  I would have thought that
configure can run normally in the combination of mingw/cygwin bash that's
used to build that way.  Instead though, I could see needing something like
config.h.msvc since configure doesn't work in that environment.

BTW, has anyone thought of using a separate config.h* for libpurple and
pidgin (and I guess finch too)?  It might make it easier to totally separate
libpurple from the rest of the codebase.  It would likely take some work but
if the public libpurple header files didn't depend on the output of running
configure, they could get distributed safely.

> > At what point in your recipe did you build with mingw?
> > It would be great to not have to do this to minimize the
> > build tool dependencies (i.e. keep developers from
> > having to deal with mingw tools at all).

> I started by following your footsteps in getting libpurple
> to work with nullclient in VS, so I had to build with
> mingw first. At first, I compiled without using a def
> file, and found that no symbols were exported in the
> resulting dll. Adding the def file fixed this. The
> alternative would be to specify all exported functions
> with __declspec(dllexport), but thats a lot of
> functions... I agree that dependence on another toolchain
> just for this is lame. I would say that distribution of
> the def file itself would be reasonable except for
> maintaining api changes.

What about something like this:

#if (defined(WIN32) || defined(_WIN32))
#define PRPL_EXTERN  __declspec(dllexport)
#else
#define PRPL_EXTERN
#endif

and then each public function starts with PRPL_EXTERN, like this:

PRPL_EXTERN PurplePlugin *purple_find_prpl(const char *id);

I'll try something like this and get it to work, then submit a patch.

-DB