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

[Alexander Neundorf]

Hi,

On Sunday 14 May 2006 15:14, Matt Rogers wrote:
> On Sunday 14 May 2006 06:09, Alexander Neundorf wrote:
...
> > I think these are really two different tasks.
> >
> > Creating as-good-as-possible build files for different build tools is the
> > main idea behind cmake. So creating really good ones for kdevelop fits
> > naturally into cmake and shouldn't be that hard. We just have to define a
> > file format and dump the data we need into this file in cmake.
> > With this enhancement every project with cmake files can be used very
> > nicely with kdevelop (just that these files still have to be
> > handwritten).
>
> KDevelop is not a build tool! KDevelop is an IDE, which means that it needs
> to be able provide a frontend for a build tool. Your thinking is backwards.
> KDevelop should be providing support for CMake, not CMake providing support
> for KDevelop, unless that support is in the form of an API kdevelop can
> hook into to manipulate CMake files.

Ok, if you argue this way, then cmake isn't a buildtool either. cmake itself 
doesn't compile anything. From this POV the buildtool is make. 

If I load a project into kdevelop, I want
-to have a list of files which belong to the project (works right now)
-the project to be compiled if I hit F8 (works right now)
-if there are serveral targets in the project, a way to select between these 
targets (works right now partly via the target selection menu)
-compile only a single source file (worked with previous cmake versions, 
doesn't work right now because the generated Makefiles changed, fixable)
-run and debug the correct executable when selecting run or debug (works right 
now for simple setups)
-provide good code navigation/autocompletion/etc. features (could work better 
if kdevelop knew the include path for each target, easy to add in the 
kdevelop generator in cmake)

What more information does kdevelop need ?
IMO it doesn't really matter whether kdevelop receives this information via 
calling functions from a cmake library or via reading its project files 
generated by cmake which contain this information.

Additionally it would be nice if I don't have to edit the cmake files 
manually, so a part/widget/tool/lib which helps there is required. This can 
be developed independently from kdevelop and then integrated in kdevelop.

This has the advantage for us, that for handling all the things listed first 
we don't have to rely on whether kdevelop parses the cmake files completely 
correctly. It will just work because cmake can tell us all of this without 
problems.

The second part, editing the cmake files, can be seen completely separated. It 
doesn't matter for kdevelop whether I edit the files manually, or whether I 
start a Qt-based "cmakeeditor" app or whether kdevelop integrates a 
QCMakeEditorWidget. It will all result in the same for kdevelop: modified 
cmake files which will again produce all information kdevelop needs.

...
> A seperate app still can't be done without a lot of extra work on the app
> developers part 

"app developer" == the developer who develops the cmakeeditor app or the 
developer who uses the cmakeeditor app ?

If the cmakeeditor would be independent from KDE and Qt-only, it could become 
a part of cmake, just as they ship ccmake and cmakesetup for windows. I'd 
consider this an advantage for us.

> and that extra work is a waste of time seeing as how the
> CMake developers have already written all the necessary code to do this.

Maybe I don't understand, but the cmake developers don't have written any code 
for editing CMakeLists.txt yet.

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