how to improve cmake support in kdevelop/ kdevelop support in cmake

Alexander Neundorf neundorf at kde.org
Sun May 14 09:49:11 UTC 2006


On Sunday 14 May 2006 03:17, Matt Rogers wrote:
> On Saturday 13 May 2006 15:43, Alexander Neundorf wrote:
...
> > Why is it unacceptable to improve the kdevelop support in cmake ?
>
> It is not, but the goal is to provide native cmake support in kdevelop.
> enhancing cmake to improve whatever kdevelop support is provided via custom
> makefiles does not help us towards the goal of providing native cmake
> support in kdevelop. 

As it is now, cmake generates project files for "custom projects". This way 
without enhancements we won't get optimal integration.
But there is nothing which hinders us to improve the kdevelop generator in 
cmake and/or create a new project type in kdevelop so that they work much 
better together.
(which still doesn't help with modifiyng the files)

> Having an API provided by the CMake developers so that
> it can be natively supported in KDevelop does help us provide native cmake
> support in kdevelop and would be the ideal situation. The next best
> solution is to do it ourselves by taking CMake's code and modifying it.
...
> I have no clue what sort of GUI i'm going to provide yet, but it won't be
> just some lineedits. But I can't even begin to provide any sort of GUI for
> this if I don't have some I can parse or get information from.

cmake syntax is simple:
commands: COMMAND (args....)
dereferencing variables: ${name_of_the_var} returns the contents of the var, 
it is always a string

Commands which we need to execute (as opposed to recognize):
MACRO()/ENDMACRO() -> insert the contents as a new command
INCLUDE()          -> insert the specified file here
FIND_PACKAGE(Foo)  -> insert the file FindFoo.cmake here
and a bunch of cmake built-in variables like CMAKE_SOURCE_DIR etc.

Maybe: SUBDIRS() and ADD_SUBDIRECTORY(): go into the subdirs

After that we would have basically "preprocessed" the cmake files and see only 
"native" cmake commands, which are not too many and we don't have to deal 
with all of them. Then we would see what goes on, but I still think creating 
a GUI powerful enough to represent this is very hard.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net




More information about the KDevelop-devel mailing list