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