Project loading (Was: KDevelop 4.0 Release)
Andreas Pakulat
apaku at gmx.de
Mon Sep 8 14:13:16 UTC 2008
On 08.09.08 10:44:59, David Nolden wrote:
> Am Montag, 8. September 2008 09:21:21 schrieb Andreas Pakulat:
> > > Even if we cached the project model, we would have to parse in case the
> > > any part of the project has been modified.
> >
> > I don't see the benefit of storing the project model. Creating the items
> > is not an expensive thing. Whats expensive is all the parsing that you
> > do ;)
> >
> > And thats the part that maybe should be stored, especially things like
> > the result of parsing FindKDE4Internal.cmake and other find-modules.
> >
> > The question that comes to my mind here is wether it would be possible
> > to analyze a CMakeLists.txt based on a DUChain model of that file. That
> > is can you store enough of the original information in DUChain to get
> > the important information out of it later on. That would give you the
> > "storage" part for free.
>
> Since cmake is already using DUChain, it should really be quite easy to use
> the. Each duchain item could just get a set of file modification-times to do
> the checking whether we need to reparse(the same thing is already done in C++
> support), and the result of parsing should be stored in form of custom
> declarations in the duchain. A straightforward way would be doing this:
> - Instead of directly populating the project tree, put all the information in
> Declarations into the DUChain, so the CMake parser just produces a set of
> top-contexts.
> When opening a project, only reparse it when the old representation is not up
> to date.
> - Use the duchain to populate the project-tree
My question was geared towards finding out wether a represenation of the
CMake files as DUChain contains enough information to
- populate the project tree
- provide include dirs
- provide defines
- allow to find the right place for updating target source file lists
Andreas
--
Perfect day for scrubbing the floor and other exciting things.
More information about the KDevelop-devel
mailing list