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

[Matt Rogers]

On Saturday 13 May 2006 15:43, Alexander Neundorf wrote:
> 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 ?
>

yes

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

It is not, but the goal is to provide native cmake support in kdevelop. 
enhancing cmake to improve whatever kdevelop support is provided via custom 
makefiles does not help us towards the goal of providing native cmake support 
in kdevelop. Having an API provided by the CMake developers so that it can be 
natively supported in KDevelop does help us provide native cmake support in 
kdevelop and would be the ideal situation. The next best solution is to do it 
ourselves by taking CMake's code and modifying it.

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

No, it's not, because it doesn't help us.

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

Who said that I wanted to provide lineedits?

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

How so?

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

I have no clue what sort of GUI i'm going to provide yet, but it won't be just 
some lineedits. But I can't even begin to provide any sort of GUI for this if 
I don't have some I can parse or get information from.
--
Matt