KDE_EXPORT question

Ralf Habacker ralf.habacker at freenet.de
Sat Apr 29 16:36:07 BST 2006


Allen Winter schrieb:
> On Saturday 29 April 2006 03:31, Andras Mantia wrote:
>   
>> Hi,
>>
>>  I have a question regarding the above define. Why should every library 
>> define its own *_EXPORT and not use KDE_EXPORT directly? Is this 
>> mandatory?
>>
>>     
> Andras,
>
> I've been working on the *_EXPORT issue in kdepim recently as well.
>
> Here's what I think to be true:
>  1. yes, each library "foo" needs its own FOO_EXPORT
>  2. each public class should be FOO_EXPORTed.
>  3. each class file fooclass.h should include "kdemodule_export.h" (kwebdev_export.h??)
>    kdemodule_export.h needs to be someplace in your module that all libraries can access
>  4. kdemodule_export.h should have a section like this
>  
>       #if defined _WIN32 || defined _WIN64 
>       # include <kdemodule_export_win.h>
>       #else /* UNIX */
>       /* export statements for unix */
>       #define KHOLIDAYS_EXPORT KDE_EXPORT  //for example
>      /* put all your FOO_EXPORT KDE_EXPORT defines here
>       #endif
>
> 5. kdemodule_export_win.h should reside in the same dir as kdemodule_export.h
> 6. kdemodule_export_win.h should have sections like the following for each FOO_EXPORT:
>
>       #ifndef KHOLIDAYS_EXPORT
>       # ifdef MAKE_KHOLIDAYS_LIB
>       #  define KHOLIDAYS_EXPORT KDE_EXPORT
>       # else
>       #  define KHOLIDAYS_EXPORT KDE_IMPORT
>       # endif
>       #endif
>
> 7. probably other stuff that I'm forgetting
>   
In case where a class is declared in one library 'FOO' and some class
methods are implemented in another library say 'BAR'

#ifndef FOO_EXTERNAL_EXPORT
# if defined(MAKE_FOO_LIB)
#  define FOO_EXTERNAL_EXPORT
# elif (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__)
#  if defined(MAKE_BAR_LIB)
#   define FOO_EXTERNAL_EXPORT __declspec(dllexport)
#  else
#   define FOO_EXTERNAL_EXPORT __declspec(dllimport)
#  endif
# else
#   define FOO_EXTERNAL_EXPORT
# endif
#endif

FOO_EXTERNAL_EXPORT should be prefixed to each related method.

The only case where this construct is used is kdelibs/kjs 
http://websvn.kde.org/trunk/KDE/kdelibs/kjs/global.h.cmake?rev=534206&view=auto 
and the original implementer had already regret this kind of 
implementation, but there may be some libraries outside, which are not 
easy to change.
:-)

Ralf







More information about the kde-core-devel mailing list