Project loading (Was: KDevelop 4.0 Release)
Hamish Rodda
rodda at kde.org
Mon Sep 8 10:21:17 UTC 2008
On Monday 08 September 2008 18: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
Sweet, this sounds like a good idea.. and almost for free :)
Cheers,
Hamish.
More information about the KDevelop-devel
mailing list