draft: cmake <-> kdevelop integration

[Matt Rogers]

On Sunday 01 October 2006 06:33, Alexander Neundorf wrote:
> 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.
>

I'm not so sure about point 2. Nobody's given me the opportunity to actually 
do any research into how hard it would be the support the majority of CMake's 
features or how long it would take for me to implement them.

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

We already don't have this as of about two weeks ago. :)

> ------------------------------------------
>
> 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 ?
>

Again, also nice, but depends upon the CMake folks releasing a library that 
will give us access to this. It also depends on CMake moving to an AST style 
storage format for their internal data structures, and I don't see that 
happening anytime soon.

> 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.
>

Yes, we would complain!! (ok, I will complain.) There are tons of issues 
surrounding a cmake library that would be able to break source and binary 
compatibility at will. In fact, it's no better than importing the cmake 
sources into kdevelop and just using those.

> 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.
>

Since I'm already going to do this for KDevelop, I'll present it to the CMake 
folks like I've done with the XML generator that KDevelop is currently using 
and if they're interested, I'll hand it off to them or let it live in their 
CVS or whatever is decided with it. 

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

This is true, but possibly fixable. I haven't tried yet.

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

That would be nice, but I doubt we'll get something like this.

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

While we would benefit from some of the things presented here (such as CMake 
providing an AST and the ability to write back CMakeLists.txt files), I feel 
a blanket mail such as this will either get ignored, met with a "please file 
a bug in the appropriate place", or some other such response. 

For now, I suggest putting this mail on hold, and continuing to work on the 
CMake support and see how far we can get without having to make heavy 
modifications to CMake. As need certain modifications, we should request 
them, and if necessary (due to time constraints), implement them ourselves. 
IOW, we should be cooperating with the CMake folks to get what we want for 
KDevelop, not sending them mails like that basically say "Hey! You need to do 
this for us! Yesterday!" 

Thanks
--
Matt