David Faure wrote:

>> - 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 macro inside qt3/win32.
> 
> 1) This doesn't appear anywhere in this patch

Yes, it wouldn't be placed explicity in the code, but using macros, see
below.

> 2) Why not use Q_EXPORT in the first place, instead of a different macro?

AFAIK, we can't, please see below.

>> - LINK_SCOPE tag is added to .kidl format.
> It's the scope of the methods, right? public vs protected, right?
> I just wonder why you call it "link" ?

I answer all your question at one time. To do this I must instroduce some
(aaargh! ;) knowledge from win32 development word. On linux, where quite
much of linkage suff coming from solaris, every symbol is (at least by
default) exported to shared libraries, so then can be reused easly.

On win32 every such symbol (specifically for us: the class name), must be
explicity tagged, to be exported or not. Not exported symbols are then not
resolved during runtime. There are two methods of making export information
available to linker:
1. Create export file and update it any time then code seems to be changed.   
It is (often) dependent on linker vendor (!) and inconvenient.
2. Add special flags to class declarations that we want to make available in
library. To do this, we should use __declspec(dllexport) in .h file, e.g.:

class __declspec(dllexport) KexiDialogBase : public QWidget { ... }
        ^^^^^^^^^^^^^^^^^
This will be ok during build of library that contains that class (here
KexiDialogBase). But .h files are used in code that links with above
library. Then __declspec(dllimport) specifier should be used instead, and
now external code can know that given class is available in dll library.

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) 

Note, that for non-win32 target, KEXICORE_EXPORT is defined empty (but shoul
be defined of course). I tend to have it defined in Makefile.am by
appending

-DKEXICORE_EXPORT= 

to KDE_CXXFLAGS. ("=" at the and is important, IMO).

There is probably method for add more automation for this...
As most of us can see (Q_EXPORT macros in .h files), TrollTech uses this
approach.

Note: Now, you probably know that "LINK_SCOPE" in .kidl means scope for
linking, not compiling.

And last note: "Why not use Q_EXPORT in the first place, instead of a
different macro?". There is need for distinguish class placed into one
library from a class placed into other library. So every set of classes
bound to given library, should contain its own unique macro. I personally
prefer to use _EXPORT prefix, what is good visible for everyone.

Example from TrollTech: EDITOR_EXPORT macro in designer/editor/browser.h in
QtDesigner.

Yes, I know all above is not important for unix, but for win32 it
unfourtanely is ;)

For interested, I'm able to send links to more detailed docs.

-- 
regards,
  Jarosław Staniek / Open Office Poland