[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:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-21 14:49:32
[Download RAW message or body]

> weis wrote:
> > 
> > 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's so true !

> > That does of course not work when users need
> > to compile with -g. How would that be with your new kDebug, David ?
As long as they don't compile with NDEBUG, even if the debug output
is turned off, they can use the new program I'll make (a separate program
for the current kdebugdialog), turn the debug output on, reproduce the bug,
and send you the result.

This will solve the problem for all snapshot-users.
But not for released stuff, because then they want speed => NDEBUG.

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

> > Bye
> > Torben
> > 
> > .... who did not printf much in the last weeks :-)
> > I converted to qDebug ...
>
> The problem with using any of this is that it still takes time
> if turned off.
I'm thinking of a global flag (in the config file and the config app)
to turn debug output off, to save time (compared to looking for the debug 
area first...). What do you think ?
Perhaps that would allow to release without NDEBUG ?

> So the user would still prefer if in final releases
> anything debug related would take 0 time. But it should still work
> without -g  in snapshots I guess :)
Yup.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

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