Performance problems in CMake support

[Andreas Pakulat]

On 01.04.08 13:57:37, Aleix wrote:
> By finder I mean a Find<PackageName>.cmake. A lot of regular expressions is
> used there.

Ah, ok.

> The problem is that I am reparsing the project every time (looking for all
> the executables and so) and now I should implement some CMakeCache.txt.

re-parsing the project on each open of the project file is fine and IMHO
the right thing. You just need to make that fast enough so people don't
notice it ;)

> I hope that this will bring some speed to the project construction.

Hmm, I'm not quite sure I understand. So currently you don't use the
values from CMakeCache.txt at all, but instead when evaluating a
FindPackage.cmake file you always evaluate it as if you had no
CMakeCache.txt? 

> I've thought about being able to open only a part of the project too,
> this would make it a little bit faster as well, you should take in
> account that a kde module is a big project itself...

I agree about kdelibs or kdebase. But kdevelop or kdevplatform aren't
that big of a project. Sure something like the python plugin in
playground is a lot smaller, but a project of the size of kdevelop
shouldn't pose a problem to our cmake support.

> It would be is to save the state of the project when closing so that when we
> open it another time it opens faster, but btw, the way cmake has to go is to
> be builddir dependent (as I said about the cmakecache.txt use).

Not necessarily, IMHO it should be possible for the cmake parser to
provide basic meaningful information by assuming <project src>/build as
builddir and using an empty CMakeCache.txt. But again, I don't know too
much about the internals of our plugin, so maybe thats just wishful
thinking on my side :)

Andreas

-- 
You enjoy the company of other people.