From kde-core-devel  Fri May 09 15:36:25 2003
From: =?windows-1252?Q?Jaros=3Faw_Staniek?= <js () iidea ! pl>
Date: Fri, 09 May 2003 15:36:25 +0000
To: kde-core-devel
Subject: Re: [QKW PATCH] dcopidl/win32
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105249458503901

Ralf Habacker wrote:
>>//for importing classes from dlls:
>>#define KEXICORE_EXPORT __declspec(dllimport)
>>//for exporting classes from dlls:
>>#define KEXICORE_EXPORT __declspec(dllexport)
> 
> It is really necessary to define macros for each library/class in kdelibs or
> other package ? What about all the additional needed support for this many
> macros.
> Wouldn't it be enough to define a KDE_EXPORT like Q_EXPORT for all this stuff
> and adding this to a basic kdelibs header, which could be used by all other
> packages ?

Note that Qt has mostly one main library for which almost everything is 
compiled in. (This is changing now, while designer plugins arrived, and 
designer editor, which is a library). Look at 
qt/tools/designer/browser.h. We have EDITOR_EXPORT used:

class EDITOR_EXPORT EditorBrowser : public QObject
...

KDE is far more structured and there are hierarchical dependencies (if I 
remember, I found even one circular!). So there is also much more places 
where new _EXPORT macros are needed. This is not a problem for GNU tools 
where every symbol seems to be exported by default . On win32 to enable 
kdelibs for developers using (also) non-gnu tools IMO, every library 
that somebody want to link against, must deliver a method for 
distinguish their components (classes) from another libraries' classes.

Lets see at this example:

libkdeui depends on libkdecore. It this situation e.g.:
in kdelibs/kdeui/kaction.cpp, <kurl.h> from kdecore is included and thus 
we need link against it.
KURL would have this definition:

  class KDE_EXPORT KURL

similar to KAction:

  class KDE_EXPORT KAction : public QObject

Ok. But we should remember that _EXPORT macros are resolved to 
something. On non-win32 these are empty macros. On win32 as Trolls do, 
we do expand *_EXPORT macro to:

__declspec(dllexport) if given class is exported in _current_ context,
__declspec(dllimported) if given class is impoted in _current_ context.

See also qt/include/qglobal.h.

And the context is the main problem. In kaction.cpp context, KDE_EXPORT 
will be resolved as __declspec(dllexport), since we want to export 
KAction and all its symbols, right? But then the same resolving will be 
also in included kurl.h file, for KURL class. It is wrong since KURL 
implementation isn't placed inside libkdeui but libkdecore, so KURL 
class impl. should be _imported_ nod exported.

Finally, to solve this conflict, we use KDECORE_EXPORT in kdecore's 
headers and KDEUI_EXPORT for kdeui lib:

kdecore/kurl.h:
  class KDECORE_EXPORT KURL

kdeui/kaction.h:
  class KDEUI_EXPORT KAction : public QObject

Now, properly both macros can be resolved during kaction.cpp compilation:
KDECORE_EXPORT --> __declspec(dllimport)
KDEUI_EXPORT --> __declspec(dllexport)

> BTW: Do you know about the started qt/win32 port on http://cygwin.kde.org  May
> be you can use some stuff of this. May be this port can use some of your stuff.
> May the efforts could be put together.

I was impressed when I had discovered your project. Sure, there is 
possiblility of our cooperation. Especially final part of your project - 
   native kde win32 port - is interesting for me. We'll be in contact ;)

-- 
regards / pozdrawiam,
   Jaros?aw Staniek / Open Office Poland
   QT-KDE-Wrapper project: http://iidea.pl/~js/qkw