[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 17:03:39
[Download RAW message or body]

David Faure wrote:
> 
> 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 ?).
Yes. SparcWorks C++-Compiler 5.0. kdelibs works fine with it, haven't
tried
other stuff, but as it's ANSI compatible it's only small glitches.
> 
> > 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, ... ) ?

Well, that would help me, not sure about others :)

Greetings, Stephan

-- 
When your memory goes, forget it!

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