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

[Alexander Neundorf]

Hi,

On Saturday 13 May 2006 20:51, Matt Rogers wrote:
> 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.

KDevelop 4 == kdevelop which comes with KDE 4 ?

Why is it unacceptable to improve the kdevelop support in cmake ?

...
> 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 don't know much about parsers and compiler etc., so maybe I'm completely 
wrong.
I think parsing cmake is not that hard. When cmake is compiled a static 
library is created which contains several functions to control cmake and 
query information.
But that's not the point.

How do you want to present a dialog with lineedits which really represents 
what the cmake files do ? I can't image how such a dialog should be 
constructed. Simple lineedits are not good enough.
E.g. a lineedit which lists all the libs an application links to doesn't 
suffice. The list of libs will be in many cases not static but depending on 
the results of configure checks:

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

find_package(JPEG)

add_executable(kfoo ...)

if (JPEG_FOUND)
   target_link_libraries(kfoo ${JPEG_LIBRARIES})
endif (JPEG_FOUND)

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

I don't see a way how to put this into a GUI.

Just listing:

Libs: " ... ${JPEG_LIBRARIES}"

might be good enough to display the used libs.
But how to remove ${JPEG_LIBRARIES} then ?
Just remove it where it is added ?
Simplest approach:

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

find_package(JPEG)

add_executable(kfoo ...)

if (JPEG_FOUND)
   target_link_libraries(kfoo )
endif (JPEG_FOUND)

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

This looks ugly, and cmake might complain about missing arguments (not sure, 
didn't test.
Ok, so if the remaining command will be empty, remove the command too:

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

find_package(JPEG)

add_executable(kfoo ...)

if (JPEG_FOUND)
endif (JPEG_FOUND)

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

cmake will eat this, but it leaves us with an empty if() clause. So let's be a 
bit more clever and remove if() if it contains nothing:

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

find_package(JPEG)

add_executable(kfoo ...)

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

Ok, cmake will be ok with this, but we still have the find_package(JPEG) line 
there (and probably an include_directories(${JPEG_INCLUDE_DIR} somewhere).

Should kdevelop know now that it can remove the find_package() call too since 
none of its variables is used anymore ?
IMO this goes too far.

The other way round also doesn't work.
Let's say the user just adds ${PNG_LIBRARIES} to the list of libs. Now, there 
still needs to be the "find_package(PNG)" somewhere. Should kdevelop now 
figure out that since the user inserted ${PNG_LIBRARIES} that there will be a 
FindPNG.cmake somewhere and that it has to insert a find_package(PNG) 
somewhere ? With or without the "REQUIRED" keyword ? In all cases or only 
under some circumstances (e.g. only on UNIX).

As I said, I don't know how to do this in a simple compile settings dialog.

I'd suggest something more wizard-like.

And, maybe a stripped down mode where kdevelop can fully edit the files, but 
only files which have been created by kdevelop itself and which have not been 
modified (or we could try to parse the files and provide a dialog if nothing 
unexpected was found, the "wizard" otherwise).

Beside that, no user who doesn't know cmake will really know what 
${JPEG_LIBRARIES} means. Even if the user wouldn't know that the variable is 
named JPEG_LIBRARIES, he would have to know that cmake takes only the 
"basename" of the library, i.e. "jpeg". He could also add "-ljpeg". But he 
has to know this in some way. Really dummy-friendly would be to have a file 
selector to chose the libjpeg.so he wants to link to. This would create 
non-dynamic cmake files which might not compile on other systems.

I guess this would have been even more impossible with scons, since this can 
be real python programs, so providing a GUI would have meant providing a GUI 
for writing python programs.

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