Gathering the set of files-to-watch
apaku at gmx.de
Wed Jun 9 20:23:39 UTC 2010
On 09.06.10 21:44:28, Esben Mose Hansen wrote:
> so having done my initial study, I'm diving into the code of KDevelop itself.
> What I want to get is a maintaned list of all files in the project. Any files
> they depend on is a bonus at the first take, though I'll need those in time as
> well. I want to use this to build a list of files that needs watching, so that
> they can be automatically reparsed when changed. By doing this, I hope to get
> to a state where renaming, find-uses and other stuff actually works most of
> the time.
> Looking at the sources, I can either get this by hooking into the
> buildmanager, the DUChain or possibly languagesupport/cpp.
You can get at all files from a project from IProject::fileSet() and
you get to all projects using the IProjectController.
> Buildmanager seems to create the parse jobs, so logically it must know which
> files are parsed.
No it doesn't. The buildmanager (e.g. cmake) only reads in its
buildsystem file and generates the project tree from that. The
parse-job thats parses all those project files after opening them is
created from projectcontroller once the project has been opened.
> The DUCHain maintains toplevel contents for each file, as far as I can see. I
> seems to get the included files here too for free, so that sounds like a
> bonus. Not sure where to put the actually "list" of watched files, though.
> Languagesupport does the parsing and adds the include jobs. I suppose this
> could be used as well.
> Any suggestions to the "right place"? I'm guessing the DUChain, but then I'll
> need a place to put the list. Perhaps in the build manager?
You mean where to put the KDirWatcher (or QFSWatcher) instance(s)? I
guess the IProject would be best, it knows about all files and doesn't
have any problems storing something for a while (as duchain has as the
duchain is serialized to disk completely - afaik).
Your present plans will be successful.
More information about the KDevelop-devel