On Thursday 28 August 2003 13:48, Ralf Nolden wrote:
> On Donnerstag, 28. August 2003 13:30, Josef Weidendorfer wrote:
> > On Thursday 28 August 2003 12:05, Andras Mantia wrote:
> > > [...]
> > > You can always make a separate release. Many applications do that,
> > > including Quanta, as we also support KDE 3.0. Personally I don't use
> > > cvs2dist, but I do it manually. It's not so hard. ;-) The only problem

Just checked a little bit.
Seems more difficult if you don't have a module on your own. E.g. I can't 
insert a configure.in.in with "#MIN_CONFIG(3)".

And where to put my version number? I used to let automake create
kcachegrind.spec/.lsm with the version number from configure.in.in...

> > > can be commits by other people which break compilation on KDE 3.0, so
> > > you must watch carefully the commit logs and try to compile it on KDE
> > > 3.0 from time-to-time.
> >
> > Ah, yes.
> > As I'm developing myself with KDE 3.1, I already have the same issue with
> > my own commits ;-)
> >
> > Nice to know that there are other apps in KDE CVS which support KDE 3.0,
> > too.
>
> So, where's the code in kdesdk ? I thought you already did that on sunday/
> monday :))

I did already some code preparation like adding GPL headers everywhere.
But replacing all qDebug with kdDebug will keep me busy for hours ;-)

I will give it a try later on, and I think I will put "kcachegrind" in 
DO_NOT_COMPILE first, enabling compiling after positive feedback.

I think I won't import calltree, as that's an independent package. Or do you 
think putting it into kdesdk/kcachegrind with conditional compiling depending 
on existance of a supported valgrind installation makes sense?

Josef