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

[Matt Rogers]

On Saturday 13 May 2006 12:18, Alexander Neundorf wrote:
> Hi,
>
> if we want to improve the cmake-kdevelop integration, there are two things
> we can do:
>
> 1) extend the kdevelop generator in cmake so that it produces more
> information which kdevelop can use
>

unacceptable for KDevelop 4.

> 2) implement a more or less complete cmake parser in kdevelop
>

Well, it'd be nice if the CMake folks could export an API we could use.

>
> With option 1) we could produce e.g. xml files which:
> -easily list all targets and commands for object files
> -list e.g. the include directories for each target (might this be useful
> for finding included headers, autocompletion, etc. ?)
> -and more things
> I think basically this would enable kdevelop to work perfectly with cmake
> builds. But it doesn't enable kdevelop to edit the cmake files.
>

That's a huge problem.

> For editing cmake files via kdevelop kdevelop would have to parse the cmake
> files. For standard cmake files this is probably not too hard. But since
> cmake features macros, conditionals, loops etc. it can get quite hard I
> think.
> E.g. let's start with something simple:
>
> Usually you specifiy an executable this way:
>
> add_executable(hello main.cpp foo.cpp)
>
> For KDE you use
>
> kde4_add_executable(khello main.cpp foo.cpp)
>
> So simple searching for add_executable() would work only in a part of the
> cases. If we start to interpret the cmake macros, we run into other
> problems:
>
> E.g. it might look like:
>
> set(mySrcs main.cpp foo.cpp)
>
> if (PNG_FOUND)
>    set(mySrcs ${mySrcs} viewpng.cpp)
> endif (PNG_FOUND)
>
> if (JPEG_FOUND)
>    set(mySrcs ${mySrcs} viewjpeg.cpp)
> endif (JPEG_FOUND)
>
> kde4_add_kcfg_files(mySrcs settings.kcfg)
>
> kde4_add_executable(kfoo ${mySrcs} )
>
> If kdevelop would interprete everything, it would end up with:
>
> add_executable(kfoo main.cpp foo.cpp viewpng.cpp viewjpeg.cpp
> xxx_settings.cpp)
>
> Then it could display in a dialog that the files named above make up the
> executable kfoo.
> But what if the user wants to add a file ?
> Simple add it at the place where add_executable() is called ? This is not
> possible, since this happens in kde/share/apps/cmake/KDE4Macros.cmake.
> Add it to kde4_add_executable() ? Not too bad. Or add it in the first set()
> command ? Probably also good.
> Or should it be added only under a certain condition as it is done with the
> viewpng.cpp and viewjpeg.cpp files ? When reading the cmake files, kdevelop
> doesn't know whether FOUND_PNG and FOUND_JPEG are true or not.
>
> How should a GUI interface for adding libraries look like ?
> Usually it is done like this:
>
> set(additionalLibs)
>
> find_package(JPEG)
> if (JPEG_FOUND)
>    set(additionalLibs ${JPEG_LIBRARIES})
> endif (JPEG_FOUND)
>
> ...
> target_link_libraries(kfoo ...some libs... ${additionalLibs})
>
> But it could also be done differently:
>
> find_package(JPEG)
> ...
>
> if (JPEG_FOUND)
>    target_link_libraries(kfoo ${JPEG_LIBRARIES})
> endif (JPEG_FOUND)
>
> The variable for the libraries are usually named this way, but not always.
> For some packages e.g. Qt, KDE4, there are also many libraries in one
> package:
>
> find_package(KDE4)
>
> target_link_libraries(kfoo ${KDE4_KIO_LIBS} ${KDE4_KDEUI_LIBS} ... )
>
> The GUI can't know that if the user enters ${KDE4_KDEUI_LIBS} in the link
> libraries line edit, that it has to add find_package(KDE4).
>
> It would be possible to edit cmake files which follow a strict convenction,
> i.e. which were created by kdevelop and not manually edited by the user.
>
> So I'm not sure that providing a conventional GUI for setting up the build
> with cmake will work good enough.
> Right know the cmake files are kdevelop project files (i.e. the
> CMakeLists.txt appear in the kfoo.kdevelop.filelist file). Maybe providing
> a "visually supported" way to edit these files would be better ?
> I.e.
> -open the cmake file in an editor window
> -provide actions/a wizard with things like:
>  - look for software package
>  - add condition
>  - add test
>  - add library/executable
>
> which will then insert the text in the open cmake file at a place suggested
> by the user.
> E.g. a dialog could appear which lists all available packages (i.e. all
> available Find*.cmake files). Then the user could select one of them and
> the find_package(JPEG) would be inserted somewhere. After that the wizard
> could show which variables are provided by this module (e.g. JPEG_FOUND,
> JPEG_INCLUDE_DIR and JPEG_LIBRARIES). Then it could ask whether to add them
> in some appropriate place in the cmake file.
> What do you think ?
>
> Bye
> Alex

IMHO, the only solution to this is to either use an API that the CMake folks 
provide to use via a library that will be installed, or we just copy all of 
CMake's code and modify it so that we can get ASTs out of the parse trees and 
upgrade everytime CMake comes out with a new release. 

I've already asked the CMake folks via kde-buildsystem for this. They said 
they'd get back to me. I'm still waiting. Hamish Rodda has also sent a mail 
asking about this.
--
Matt