draft: cmake <-> kdevelop integration

[Alexander Neundorf]

Hi kdevelop developers,

after the BoF we had during akademy I wanted to write an email to the cmake 
devs about what we need for kdevelop.
Here's a first draft.
Please comment, edit, etc.

Bye
Alex

Hi,

during akademy we had a kdevelop Bof (I'm also a minor contributor to 
kdevelop) and one of the topics we discussed was how to integrate cmake and 
kdevelop best.

We were:
Alex Dymo
Naadem Hasan
Jakob Petsovits
Adam Treat
Alex Neundorf

and unfortunately not:
Matt Rogers
Bill Hoffman

We didn't come to a real conclusion, but we all agreed on these points:

1) With KDevelop it must be possible that the user can create simple projects 
without having to edit text files.

2) It will not be possible to completely support all CMake features in 
KDevelop via a GUI, so for complex cmake files the user will have to learn 
cmake and edit the cmake files manually.

3) We do not want to have a cmake fork in the kdevelop sources.

------------------------------------------

Simple projects:

The user creates a new project, and then he is able to add files to the 
project, he can add include directories, he can add libraries he wants to 
link to. 
This should also work for existing cmake projects, as long as they have 
not-too-complex cmake files.
It also means that kdevelop needs a way to write cmake files.

This already has several problems. Let's image a cmake file like this:

---------8<------------8<-------------8<----------
#00 
#01 set(myLinkLibs foo)
#02 set(myIncDirs foo/include)
#03 
#04 set(mySrcs main.cpp foo.cpp)
#05 
#06 find_package(PNG)
#07 
#08 if (PNG_FOUND)
#09    set( mySrcs ${mySrcs} pngview.cpp)
#10    set(myLinkLibs ${myLinkLibs} ${PNG_LIBRARIES})
#11    set(myIncDirs ${myIncDirs} ${PNG_INCLUDE_DIR})
#12 endif (PNG_FOUND)
#13
#14 if (WIN32)
#15    set( mySrcs ${mySrcs} pngview.cpp)
#16 else (WIN32)
#17    set( mySrcs ${mySrcs} pngview.cpp)
#18 endif (WIN32)
#19
#20 include_directories( ${myIncDirs})
#21
#22 add_executable(hello ${mySrcs})
#23
#24 target_link_libraries(hello ${myLinkLibs})

---------8<------------8<-------------8<----------

So in this case, if the user wants to add a source file, where should it be 
added ?
Line 4, 9, 15, 17 or 22 ?
Or just insert something like

set(kdevAddedSrcs somefile.cpp)

add_executable(hello ${mySrcs} ${kdevAddedSrcs})

?

Similar problem for adding libraries.
Ideally, if you want to use the png lib with cmake, it should be done as in 
the example above, i.e. using FIND_PACKAGE() and then using the variables 
coming from this module. If a dialog just provides a lineedit for inserting 
libs to link to this is suboptimal.

Ok, anyway, if we want to provide good support for basic projects, kdevelop 
must be able to read the cmake files and understand them more or less. 
Can cmake offer an AST ?

AFAIK the cmake devs don't want to release a shared cmake library for various 
reasons. We as KDevelop developers promise that we would not complain if such 
a hyptothetical library would break source/binary compatibility.

Would you, the cmake developers, accept a contribution which adds a powerfull 
Qt widget for editing the cache, and also advanced support for creating cmake 
files (with intelligent autocompletion, maybe wizard-style stuff, etc.) ? 
This QWidget would be available via a shared lib, so that we could create a 
KPart from this widget and embed it into kdevelop.

AFAIK if a cmake generator will generate a list of source files for each 
target, but the conditions are lost at this point.

Is there a chance that we might get something from you (the cmake devs) which 
allows us to *write* cmake files ? 

We could do "managed cmake" projects, where only kdevelop creates the cmake 
files and so it knows everything about them. 

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