view libpurple/dbus-define-api.h @ 24389:2b62300d2c19

Use libtool to build static archives when --with-static-prpls is passed to configure. Does anyone know why we weren't using libtool before? We were building old-fashioned .a files. But libtool archives (.la) can contain either static or shared libraries. I found it a lot easier to get static prpl compilation working after making this change (that is to say, it worked). Without this I got this error, which is probably fixable, but consistently using libtool seems like it makes things easier: *** Warning: Linking the shared library libpurple.la against the *** static library ../libpurple/protocols/msn/libmsn.a is not portable! /usr/bin/ld: ../libpurple/protocols/msn/libmsn.a(libmsn_a-msn.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../libpurple/protocols/msn/libmsn.a: could not read symbols: Bad value collect2: ld returned 1 exit status

#error "This is file is not a valid C code"

/* This file contains some of the macros from other header files as
   function declarations.  This does not make sense in C, but it
   provides type information for the dbus-analyze-functions.py
   program, which makes these macros callable by DBUS.  */

/* blist.h */
gboolean PURPLE_BLIST_NODE_IS_CHAT(PurpleBlistNode *node);
gboolean PURPLE_BLIST_NODE_IS_BUDDY(PurpleBlistNode *node);
gboolean PURPLE_BLIST_NODE_IS_CONTACT(PurpleBlistNode *node);
gboolean PURPLE_BLIST_NODE_IS_GROUP(PurpleBlistNode *node);
gboolean PURPLE_BUDDY_IS_ONLINE(PurpleBuddy *buddy);
gboolean PURPLE_BLIST_NODE_HAS_FLAG(PurpleBlistNode *node, int flags);
gboolean PURPLE_BLIST_NODE_SHOULD_SAVE(PurpleBlistNode *node);

/* connection.h */
gboolean PURPLE_CONNECTION_IS_CONNECTED(PurpleConnection *connection);
gboolean PURPLE_CONNECTION_IS_VALID(PurpleConnection *connection);

/* conversation.h */
PurpleConvIm *PURPLE_CONV_IM(const PurpleConversation *conversation);
PurpleConvIm *PURPLE_CONV_CHAT(const PurpleConversation *conversation);