[QKW PATCH] dcopidl/win32
Jaros?aw Staniek
js at iidea.pl
Fri May 9 17:32:31 BST 2003
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
More information about the kde-core-devel
mailing list