KDE/kdevelop/buildtools/managers/cmake

[Alexander Neundorf]

On Wednesday 03 September 2008, Aleix Pol Gonzalez wrote:
> SVN commit 856474 by apol:
>
> Let CMake work with subprojects.
>
> This is a very usual use case and a place where many people found "buggy"
> the way to work because when importing a subproject made KDevelop to mess
> up because of the non-parsed CMakeLists.txt files placed in parent
> directories. 

This is actually how it should be.
There is no guarantee at all that you can run cmake on a CMakeLists.txt in an 
arbitrary directory of a project and it will work.
This works only if the developer intended that subdirectory to be used 
stand-alone without the rest of the project.
This works e.g. for automoc4, the top level subdirs in kdebase and some 
others.

> Now KDevelop looks if there are and it parses them too.
> **Warning** it will always look for it, it is not yet configurable in the
> project file (it is configurable in the .kdev4/project.kdev4 file, should
> be moved)

So you are aware that this will be correct only in most of the cases, but not 
in all cases ?

> Now it is possible to parse a cmake subproject without parsing the other
> subdirectories below or in the same level. It can be useful when you are
> working on a large project and you don't need the whole to be supported by
> KDevelop (for instance, when I'm working on KAlgebra in KDE-Edu, I don't
> need, let's say, the Marble buildtool information).

In many cases this is true, but not in all cases.
In other subdirectories cache values could be set or global or directory 
properties could be set, or targets could be created. All this is global 
information which can influence parent and sibling directories (actually 
all "relatives"). There are real-world projects which do this.

Alex