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

[Matt Rogers]

On Sunday 14 May 2006 08:38, Alexander Neundorf wrote:
> Hi,
>
> On Sunday 14 May 2006 15:14, Matt Rogers wrote:
> > On Sunday 14 May 2006 06:09, Alexander Neundorf wrote:
>
> ...
>
> > > I think these are really two different tasks.
> > >
> > > Creating as-good-as-possible build files for different build tools is
> > > the main idea behind cmake. So creating really good ones for kdevelop
> > > fits naturally into cmake and shouldn't be that hard. We just have to
> > > define a file format and dump the data we need into this file in cmake.
> > > With this enhancement every project with cmake files can be used very
> > > nicely with kdevelop (just that these files still have to be
> > > handwritten).
> >
> > KDevelop is not a build tool! KDevelop is an IDE, which means that it
> > needs to be able provide a frontend for a build tool. Your thinking is
> > backwards. KDevelop should be providing support for CMake, not CMake
> > providing support for KDevelop, unless that support is in the form of an
> > API kdevelop can hook into to manipulate CMake files.
>
> Ok, if you argue this way, then cmake isn't a buildtool either. cmake
> itself doesn't compile anything. From this POV the buildtool is make.
>

You're right, I don't consider CMake to be a build tool. I consider CMake to 
be the build system.

> If I load a project into kdevelop, I want
> -to have a list of files which belong to the project (works right now)

Which we should be able to get from the build system, ideally.

> -the project to be compiled if I hit F8 (works right now)
> -if there are serveral targets in the project, a way to select between
> these targets (works right now partly via the target selection menu)
> -compile only a single source file (worked with previous cmake versions,
> doesn't work right now because the generated Makefiles changed, fixable)
> -run and debug the correct executable when selecting run or debug (works
> right now for simple setups)
> -provide good code navigation/autocompletion/etc. features (could work
> better if kdevelop knew the include path for each target, easy to add in
> the kdevelop generator in cmake)
>
> What more information does kdevelop need ?

a lot more if it does what i want it to do, and that is to be able to edit and 
change nearly every aspect of the build system that can be changed. After 
all, VC++ can do this, why shouldn't we be able to? I believe that people 
expect that out of an IDE.

> IMO it doesn't really matter whether kdevelop receives this information via
> calling functions from a cmake library or via reading its project files
> generated by cmake which contain this information.
>
> Additionally it would be nice if I don't have to edit the cmake files
> manually, so a part/widget/tool/lib which helps there is required. This can
> be developed independently from kdevelop and then integrated in kdevelop.
>
> This has the advantage for us, that for handling all the things listed
> first we don't have to rely on whether kdevelop parses the cmake files
> completely correctly. It will just work because cmake can tell us all of
> this without problems.
>

If the CMake developers would provide an API that gave us an abstract syntax 
tree or some other data structure with the required information, we wouldn't 
have to parse anything correctly!!

> The second part, editing the cmake files, can be seen completely separated.
> It doesn't matter for kdevelop whether I edit the files manually, or
> whether I start a Qt-based "cmakeeditor" app or whether kdevelop integrates
> a QCMakeEditorWidget. It will all result in the same for kdevelop: modified
> cmake files which will again produce all information kdevelop needs.
>

And that editor thing, whatever it is, would still be useless to us in ways 
that i'm tired of trying to explain unless someone wrote it from the point of 
view of an IDE developer.

>
> > A seperate app still can't be done without a lot of extra work on the app
> > developers part
>
> "app developer" == the developer who develops the cmakeeditor app or the
> developer who uses the cmakeeditor app ?
>

the developer who developers the cmakeeditor app.

> If the cmakeeditor would be independent from KDE and Qt-only, it could
> become a part of cmake, just as they ship ccmake and cmakesetup for
> windows. I'd consider this an advantage for us.
>

I wouldn't. See above about editing the CMake files.

> > and that extra work is a waste of time seeing as how the
> > CMake developers have already written all the necessary code to do this.
>
> Maybe I don't understand, but the cmake developers don't have written any
> code for editing CMakeLists.txt yet.

No, you don't understand. I don't need code to write CMake files from the 
CMake developers. How can I make that any clearer? I need code that will let 
me use the information that CMake's code already collects from the files when 
they get read by CMake! The CMake folks don't need to write any code for 
writing CMakeLists.txt files. But KDevelop will and all I'm trying to do is 
to get an API I can use so I don't have to spend time writing code that 
duplicates something that's already been done! Do you understand now?

PLEASE, take off your CMake hat for a second and make an attempt to understand 
my point of view as the developer of an IDE whose users have already 
requested native support for CMake because i'm tired of trying to explain it 
to you.
--
Matt