From kde-devel  Thu Sep 11 14:54:35 2003
From: Kuba Ober <kuba () mareimbrium ! org>
Date: Thu, 11 Sep 2003 14:54:35 +0000
To: kde-devel
Subject: Re: [patch] request for review - apidox for kdelibs/kdeui (long)
X-MARC-Message: https://marc.info/?l=kde-devel&m=106329230000880

On wtorek 09 wrzesień 2003 06:43 am, Stephan Kulow wrote:
> On Tuesday 09 September 2003 12:20, Brad Hards wrote:
> > On Tue, 09 Sep 2003 20:00 pm, Stephan Kulow wrote:
> > > > In that case, wouldn't it make more sense not to define KDE_NO_COMPAT
> > > > when building the documentation:
> > >
> > > [patch]
> > >
> > > This would make all the deprecated API calls invisible to doxygen and
> > > you have no way to document it.
> >
> > OK, then I'm confused again. If we #define KDE_NO_COMPAT, we remove
> > reference to all the deprecated calls (since they are all wrapped in
> > #ifndef), which is not what we want.
> >
> > Can you explain this to me again?
>
> s,calls,methods, in my statement
>
> In a book you don't want to tell about the deprecated API, but in an online
> docu you want people to find out what they should use instead when they
> port their apps. But if you predefine KDE_NO_COMPAT, then doxygen doesn't
> see that docu at all.

Here's what Brad said:

[...]
> > In that case, wouldn't it make more sense not to define KDE_NO_COMPAT when
> > building the documentation:
[...]
-PREDEFINED             = QT_VERSION=320 __cplusplus KDE_NO_COMPAT
+PREDEFINED             = QT_VERSION=320 __cplusplus

*not to define* means that KDE_NO_COMPAT will be gone when building the docu. 
That's what Brad proposes, and that's what you want, so I think you misread 
his post.

Tthe KDE_NO_COMPAT is there *now* but it *should be gone,* because otherwise 
the online docu doesn't properly document deprecated stuff.

So, violent agreement it is (per Brad's words). I guess Stephan is sleep 
deprived, or tries to cheat with quick reading strategies :)

Cheers, Kuba Ober

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<