[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RE: [QKW PATCH] dcopidl/win32
From:       "Ralf Habacker" <Ralf.Habacker () freenet ! de>
Date:       2003-04-29 20:22:43
[Download RAW message or body]

Hi Jaroslaw,

> Ralf Habacker wrote:
> > > This is only true, if you don't use g++/ld (mingw or cygwin based) on
> > win32, because the mingw/cygwin ld contains special support to ensure
> > mostly linux compatibility on windows. With this feature, the kde-cygwin
> > releases could be build without any of this dump declspec stuff.
> > Right. But:
> 1) We all wish to have good-working g++ on win32 with supported Qt3 and able
> to link with 3rd party binary-only libraries. At the time I can't even ask
> developers (even non-commercial) to wrap everything such low-level as
> linking system, runtime names resolving, etc.
> Personally, I also just don't want to patch M$ tools again and again to get it
closer to POSIX ;)
> 2) AFAIK Trolls don't supports g++ for Qt3/win32. More, currently on win32
> most people uses Borland or M$ tools as these tools are only fraction of
> qt/win32 cost.
> Although, I wish to have g++ on TrollTech's list of supported win32 compilers.
> 3) Note that everything I writing in context of win32 part of QKW, is not
> related to qt/X11 compiled under Cygwin, but native qt/unix, qt/win32 and
> qt/macosx targets.
>

Thank you for this explantions.

Let me ask at last one question:

>> - Class declarations with __declspec(import) and __declspec(export) flags
>> are now handled properly. It's used on win32 by defining e.g.
>> KDECORE_EXPORT macro, similarly to Q_EXPORT

<snip>
>To have just one definition for each class, we tend to introduce macro that
>has different value, depending on what we compile now, e.g:

>//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 ?

I can't imagine a condition where I would use one macro with and one macro
without such a declspec statement, because for c++ I'm forced to use the same
compiler to compile and link all c++ code.

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.

Cheers
Ralf


[prev in list] [next in list] [prev in thread] [next in thread]