KDE/kdevelop/buildtools/managers/custommake

[dukju ahn]

2007/5/31, dukju ahn <dukjuahn at gmail.com>:
> 2007/5/31, Andreas Pakulat <apaku at gmx.de>:
> > On 31.05.07 13:07:38, dukju ahn wrote:
> > > 2007/5/30, Andreas Pakulat <apaku at gmx.de>:
> > > > On 30.05.07 19:11:50, Dukju Ahn wrote:
> > > > > SVN commit 669909 by dukjuahn:
> > > > >
> > > > > Implementing Directory watcher in custom make manager.
> > > >
> > > > 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).
> > >
> > > One problem on directoryChanged() slot is regarding the Makefile. If makefile
> > > is *created*, the slot should update the list of target. Problem happens
> > > because each manager has different name of makefile(CMakeList, *.pro, *.am etc)
> > > Moreover, IBuildSystemManager:;findMakefiles(KDevelop::ProjectFolderItem*)
> > > cannot be used because QMakeManager doesn't fetch the .pro list from disk --
> > > it fetches from projectfolderitem, which cannot reflect newly created file.
> >
> > You misunderstood, I think. What I meant should be factored out is
> > wether files/dirs where added or removed from a directory and then emit
> > a proper signal like "addedEntries(KUrl::List)" and
> > "removedEntries(KUrl::List)". Yes that needs some additional data to be
> > stored (the "old" list of entries in a directory). I didn't mean you
> > should move project-related stuff into the file. Also it would be more a
> > KDevelopFileSystemWatcher then.
>
> Oh I see. I misunderstood. But my intention was similar with you anyway :)
> See below.
>
> > > So, I'll add "virtual Watcher::fileCreated( QString filePath,
> > > ProjectFolderItem* parent )"
> > > and each managers only have to reimplement this small method.
> >
> > I don't see what you mean specifically, where do you want to add this
> > method, from where would it be called?
>
> Rather than emitting removedEntries(), having virtual interface is more good.
> This virtual interface will be called instead of emitting signal.
> And each managers just implement their own removedEntries() and somthing.

Also, if we use virtual interface, the library can provide default
implementations
for directoryCreated() and directoryDeleted().  Especially, the event
of directory
creation/deleting does not involve project stuff -- because if
projectfiles (.pro .am)
get some changed, they are notified via fileCreated()/deleted(), not
directoryXX().