Moving kfilereplace to kdeutils

[Josef Weidendorfer]

On Saturday 13 November 2004 00:46, Michael Nottebrock wrote:
> On Friday, 12. November 2004 22:56, Jonathan Riddell wrote:
> > On Fri, Nov 12, 2004 at 08:06:07PM +0100, Michael Nottebrock wrote:
> > > Thinking about it, most of the recent
> > > additions to kdesdk really would lead a better life in KEG, kompare,
> > > umbrello, kcachegrind...
> >
> > I don't see why.
>
> Some reasons:
>
> - They're not really part of a KDE SDK, they're general purpose development
> tools. So you might say "big deal, we just rename kdesdk to
> kdevelopmenttools then", but:

Hi,

of course, we can split kdesdk in the real KDE-only SDK part and into 
kdevtools (But I don't see the real benefit. Packagers do their own 
splitting).
And as was said, the candidates for kdevtools want to be part of the KDE 
release cycle. KCachegrind is no exception here ;-)

> - There's no real benefit for those applications being tied to the KDE
> release cycle. For KCacheGrind, it's even suboptimal - it should rather be
> synced with valgrind.

Wrong. KCachegrind is a general visualization tool for profile data and the 
data format is quite general. The only  link to valgrind is the name 
("historical") and the ability to directly load data produced by valgrind 
tools like cachegrind or callgrind. But there are also a few format 
converters to load data produced by OProfile, Python/PHP interpreters or 
memprof.

Josef