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

List:       kde-core-devel
Subject:    Re: RFC: Strategy for integrating the Nana debugging library
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-12-21 12:42:10
[Download RAW message or body]

David Faure wrote:
> 
> I had some more thoughts about the Nana/kDebug issue.
> 
> I'd like you (everybody) to think of the issue KDE-wide, not
> only one-app-wide. Having to compile something with -g simply to get
> debug output out of it is nonsense, when you think of it KDE-wide.
> Some people hack on (/develop/maintain/...) their app only, and that's
> great. But some other people (I fall in this category, and a lot of other
> developers as well) fix bugs all over KDE, whenever they see one.
> Would those people have to compile all of KDE with -g ? That would be
> nonsense.
> 
> Even more, apps such as kioslaves are more easily debugged by looking at
> their
> output than by running then in gdb.
> 
> If there is a strong demand from app developers that want to use nana, fine
> with me. But I think the core libraries, the kioslaves, and even the rest
> (those apps that everybody hack one day or another, such as kdebase), should
> rather use an improved kDebug, like the one I suggested.
> 
> * Simple API (kDebug(message) for apps, kDebug(area,message) for libs or
> apps
>   that want to use debug areas)
> * Easily turned on/off/syslogged (with a separate program)
> * Default config file, so that debug info not relevant to most developers is
> turned
>   off (just like KRun is turned off manually currently)
> * Debug info automatically turned off for releases (not warnings/errors)
> (see my initial proposal for more details).
> 
> To me, this looks like the best KDE can get in terms of debug output, and
> displaying of warnings and errors.
> 
> For assertions and other checks, nana brings more, but a new lib for only
> that seems overkill to me, and if that's only available with -g, see above.
> In that case (requires -g) I think that improving or writing stuff like
> kAssert, kEnsure... would be a better solution. And not very complex to do
> at all
> (this is not stupidly reinventing the wheel). It's taking some good ideas
> out
> of something that doesn't have the right approach for KDE (requires -g,
> requires gdb...)
> 
> Something else: I'd also like kDebug to show filename and line, but that
> means
> turning it back into a macro. Well, just like nana does, but we moved away
> from the KDEBUG macros (one per number of args) for some reason I forgot
> (I thought it was because macros with var args were not supported, but
> according to nana they are...).
Well, variable args not, different number of args yes :)
> 
> I am a bit disappointed that while I try to discuss things, and before
> there was any kind of consensus, nana was simply imported into kdelibs. Now
> I
> look like the guy who want to destroy existing code, whereas I'm not, and
> I'm really thinking in terms of what's best for KDE.
> Code counts, yes, but deciding before coding counts as well.
> 
> Opinions, please !
> 
Well, I don't see why nana can't be used side by side to kdebug. Those
that
want nana can - it's after all a very tiny library (and I compile with
-g
everything since I compile KDE at all [actually --enable-debug was the
very
first configure switch we had]). But your kdebug changes should
definitly go
in, you're right that we shouldn't make our developers after libraries,
but
our libraries after our developers. And history showed that whatever we
gave
them, they printf()ed ;-)

But I would use asserts that can give me more output than "it was wrong"
anytime
I can.

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online

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