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

[Hamish Rodda]

On Sunday 14 May 2006 19:49, Alexander Neundorf wrote:
> On Sunday 14 May 2006 03:17, Matt Rogers wrote:
> > On Saturday 13 May 2006 15:43, Alexander Neundorf wrote:
>
> ...
>
> > > 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.
>
> As it is now, cmake generates project files for "custom projects". This way
> without enhancements we won't get optimal integration.
> But there is nothing which hinders us to improve the kdevelop generator in
> cmake and/or create a new project type in kdevelop so that they work much
> better together.
> (which still doesn't help with modifiyng the files)

As an interim measure, supporting better cmake created .kdevelop files would 
be ok, as long as the effort is trivial in comparison to that needed to get 
full 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.

Not only do we need to be able to parse cmake files, but we need to be able to 
evaluate them just like cmake.  Which hopefully could come from a cmake api.

However seeing as there was no response to my email (maybe I need to try the 
cmake list as well), i doubt it will happen anytime soon, and perhaps we 
should look at creating one ourselves and proposing it to the cmake devs.

> > 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.
>
> cmake syntax is simple:
> commands: COMMAND (args....)
> dereferencing variables: ${name_of_the_var} returns the contents of the
> var, it is always a string
>
> Commands which we need to execute (as opposed to recognize):
> MACRO()/ENDMACRO() -> insert the contents as a new command
> INCLUDE()          -> insert the specified file here
> FIND_PACKAGE(Foo)  -> insert the file FindFoo.cmake here
> and a bunch of cmake built-in variables like CMAKE_SOURCE_DIR etc.
>
> Maybe: SUBDIRS() and ADD_SUBDIRECTORY(): go into the subdirs
>
> After that we would have basically "preprocessed" the cmake files and see
> only "native" cmake commands, which are not too many and we don't have to
> deal with all of them. Then we would see what goes on, but I still think
> creating a GUI powerful enough to represent this is very hard.

I think it's quite solvable; eg., when you add a file to a target, if the 
sources for that target come from more than one part of the cmake file 
(variable, etc), we just ask the user which part they want the file added to.  
As long as the variables have reasonable names, it should be pretty easy for 
most users to pick the best answer.

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060514/9344c34d/attachment.sig>