Hi,

I think David has really a point here.

BTW: Often I wish I could tell users:
Turn on debug output, do this and that and mail
me the output. That does of course not work when users need
to compile with -g. How would that be with your new kDebug, David ?
Will the debug stuff remain or go out because of performance
and memory bloat ? The last alternative, I assume ...

However, I usually dont compile kword etc. with -g because of
time/space. Being able to turn on debug output nevertheless
would be a nice thing to prevent recompiling it every time.

Bye
Torben

.... who did not printf much in the last weeks :-)
I converted to qDebug ...

On Tue, 21 Dec 1999, Stephan Kulow wrote:

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