KDE/kdevelop/buildtools/managers/custommake
Andreas Pakulat
apaku at gmx.de
Thu May 31 22:07:27 UTC 2007
On 31.05.07 16:41:57, Matt Rogers wrote:
> On Wednesday 30 May 2007 14:35, Andreas Pakulat wrote:
> > On 30.05.07 19:11:50, Dukju Ahn wrote:
> > > SVN commit 669909 by dukjuahn:
> > >
> > > Implementing Directory watcher in custom make manager.
> >
> > Good that you used QFileSystemWatcher and not KDirWatch (the latter one
> > has a couple of shortcomings). The stuff you do inside the directory
> > changed slot should probably go into the filesystem watcher class and
> > then the whole class should go somewhere into lib/ so other project
> > managers can benefit from that (QMake will need this too).
> >
> > KDirWatch still exists, but I'm actually not even sure if it works on
> > windows (where QFileSystemWatcher works for sure), it as a bit more
> > fine-grained signals, unfortunately a couple of the features are not
> > implemented. (This is mainly for Matt to explain why QFileSystemWatcher
> > is the better alternative)
>
> I don't know why it's better. :P
One of the most obvious problems of KDirWatch is that it uses fam or
gamin when they are available. The first one is unmaintained and has
serious runtime problems (cpu hogging), the second is a drop-in
replacement but I've read about problems with that too.
KDirWatch is unmaintained in kdelibs (more or less), there's a thread
where I asked about its future and wether some of the functions that are
currently not implemented will become so, but IIRC the answer was no.
Last but not least: The platform issue, as far as I see KDirWatch would
use polling on Windows while QFileSystemWatcher uses a win32 API (as far
as I can see).
So for the long run I think with QFileSystemWatcher we're on the safe
side, even though we need to add a few convenience things.
Andreas
--
Good news from afar can bring you a welcome visitor.
More information about the KDevelop-devel
mailing list