From kde-core-devel  Tue May 29 12:27:59 2001
From: Lars Knoll <lars () trolltech ! com>
Date: Tue, 29 May 2001 12:27:59 +0000
To: kde-core-devel
Subject: Re: exporting symbols (was Re: The goodness of goodness)
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=99113942805172

Hi,

I'd prefer this approach. It's sort of complementory to the one we use in Qt
(We use Q_EXPORT for all classes we want to export). This is due to the fact
that Windows needs an explicit __declspec(dllexport) for classes that should
be exported from a dll.

Maybe this is even a better option for KDE (at least for whole classes). Mark
all classes that should get exported and assume the others to be internal. It
has the advantage, that you will immediately notice when you forgot exporting
a class. Noticing the other way round (we have an internal class we export by
mistake) is much harder, as it'll only show up by inspecting the source or
the exported symbols of the shared lib.

Otherwise I think we should default to not exporting private methods (except
where otherwise marked). This should already give us most of the effect we
want to achieve with a minimum amount of work/changes in the source.

So I'd rather vote for a KDE_EXPORT macro than a KDE_PRIVATE one.

Lars

On Tuesday 29 May 2001 13:15, Michael Matz wrote:
> Hi,
>
> On Tue, 29 May 2001, Dirk Mueller wrote:
> > All we can do is try it. such a parser can't be too difficult. should we
> > start with kdoc or with dcopidl ? :)
>
> I wanted to originally base it on dcopidl to accept something like this
> syntax:
>
> class KDE_PRIVATE MyClass:public BaseClass,private PClass {
> ...
> };
>
> to make all symbols resulting from class MyClass non-public;
>
> class Bla {
> public:
>   KDE_PRIVATE int internal_method (int whateever);
> };
>
> to make this one method non-public, and:
>
> class Blubb {
> public:
> KDE_START_PRIVATE
>   int method1();
>   void another_method();
> KDE_STOP_PRIVATE
>   int visible_method();
> };
>
> to make all methods between the obvious pair non-public.
>
> To be compatible with C++, this somewhere needs #define'ing away the
> KDE_*PRIVATE tokens.  So we don't need to process comments.
>
> One problem which needs thought is: what happens with inherited symbols?
> The most simple (and arguable most correct) method is to really only make
> those symbols non-visible, which are explicitely mentioned, which then
> means, that this is possible:
>   class A {public: int m();};
>   class B:public A {public: KDE_PRIVATE int m();};
> and means A::m() is visible, but B::m() not, which _might_ have issues
> with virtuality (what is, if m is virtual, another DSO defines a class C
> based on B, and calles m().  There _should_ be linker errors, but this
> needs investigation).
>
> With regard to kdoc: the tool should be run as part of the build system,
> and right now we don't require perl for a simple make, with kdoc we would.
>
>
> Ciao,
> Michael.