[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:45:24
[Download RAW message or body]

Stephan wrote :
> Well, I don't see why nana can't be used side by side to kdebug.
Sure. As I said : fine with me if applications developers use nana,
as long as kDebug is the one used for debug output, for the reasons 
I explained already many times.

But only if it doesn't prevent from compiling KDE with other compilers
than gcc (it is possible to do that, right ? Your "patch for CC5" for Qt,
is it about a compiler ?).

> Those that want nana can - it's after all a very tiny library 
Yes, if it doesn't limit KDE to gcc (provided that it wasn't already limited
to it).

> (and I compile with -g everything since I compile KDE at all 
> [actually --enable-debug was the very first configure switch we had]). 
:-) Well, not everybody does that. Especially not users, even the ones
that use bleeding edge KDE and report bugs !

> 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 ;-)
Exactly :-)
And raw printfs are evil because they can't be turned off.

> But I would use asserts that can give me more output than "it 
> was wrong" anytime I can.
Well if that's the only reason for nana, what about
void kAssert( bool condition, const char *fmt, ... ) ?

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