KDE/kdevelop/languages/cpp

[Alexander Neundorf]

On Wednesday 27 June 2007 07:46, Matt Rogers wrote:
> On Jun 26, 2007, at 10:00 PM, Alexander Neundorf wrote:
...
> > CMake is no standardized language, so it can be extendend and new
> > stuff can be
> > added.
> >
> > How is all this handled ?
> >
> > Alex
>
> The same that CMake does it, via parsing and intrepretation.


I discussed with Bill Hoffman and he agrees completely with me.
Let me put it this way: 

this approach is broken by design and *CAN* never work reliably.

You are reimplementing parts of cmake in kdevelop.

cmake is no fixed language implemented after a standardized definition.

It can and does evolve, and with reimplementing it, kdevelop will always have 
to track any changes in cmake and reimplement every special behaviour in 
cmake. E.g. there are several things in cmake just forbackwards 
compatibility, if kdevelop wants to understand the cmake files, it has to 
understand 100% of this.

You have to implement at least among others:
include()
include_directories()
macro/endmacro()
if/endif/foreach/endfroreach/while/endwhile
env[] syntax
execute_process
exec_program
find_package
find_path, find_file, find_library, find_program
string(...)
file(...)
set_[target/directory/sourcefiles]_properties
get_[target/directory/sourcefiles]_property

Without full support for all of these kdevelop cannot get everything right. It 
also means implementing all the environment variables cmake supports (e.g. 
CMAKE_PROGRAM_PATH or CMAKE_FRAMEWORK_PATH on OSX). This has to be 
implemented for all supported platforms (UNIX, OSX with its frameworks etc., 
Windows).

Just as an example what you can do with current cmake cvs:

somewhere in any directory:
set_property(GLOBAL PROPERTIES MY_INC_DIR /opt/foo )

e.g. later on in the top level CMakeLists.txt:

get_property(INC_DIR GLOBAL MY_INC_DIR)
include_directories(${INC_DIR})


Does this work with the current cmake support in kdevelop ?
Of course you can implement it, but this will be ALWAYS the case, kdevelop 
will always understand only part of the existing cmakefiles for some versions 
of cmake. 

So the support in kdevelop if done this way will ALWAYS be buggy.

All this would still be acceptable if there would be no better way to do it. 
But that's not the case here, you are working around one of the major 
purposes of cmake, the generators.

The purpose of the generators in cmake is just that, output all the 
information an IDE needs in the format the IDE needs. Every night complete 
builds and a bug suite of unit tests is run on cmake for all supported 
platforms and generators, if something breaks, it gets fixed within a few 
days.

With doing this as a generator in cmake we get:
-*MUCH* less work for us
AND
-*100% reliable data* (except the bugs any software has from time to time)
-all the cross platform features cmake already has

Which information does kdevelop need ?
-the targets
-the executables so the debugger knows what to run
-the include paths for the targets
-the files which belong to a target
-cmake also has support for just preprocessing or compiling up to the 
assembler step, so kdevelop needs to know the name of the rule and where the 
file goes
-included files ? cmake does complete dependency scanning, so it should be 
easy to get this information for the generator

I strongly recommend the following approach:

* simple projects

add a copy of a known to be working cmake release to kdevelop (e.g. 2.4.5) and 
use this internally for simple projects where the user just clicks some stuff 
together. He can do this completely GUI driven, add a target, use the file 
dialog to select libs to link to, to select include dirs, to add files. When 
building generate the CMakeLists.txt from this information and run the 
internal cmake on it. Disable manual editing of the generated files by 
enabling CMAKE_SUPPRESS_REGENERATION, so cmake will not run automatically if 
the user finds the generated cmake files and modifies them.
This will work without problems for simple "I just want to write a program and 
not really care about how to build it" programs.

* advanced projects

The user is a developer, he is able to write programs in C or C++, so if he 
wants to write software which is portable to other systems he really should 
be able to learn cmake. Don't hide it from the developer.
Now in current cmake cvs adding generators for makefile based projects has 
become easier. Let's add a KDevelop4 generator which gives kdevelop all the 
information it needs.
This will have the HUGE advantage that it will work with every new features 
introduced in cmake, kdevelop will simply not have to play catchup all the 
time just to maintain a somewhat working state.

The developer will have to know cmake. This is ok.
If he wants to write portable software, he HAS to care about build issues. 
Otherwise it simply will not work.

What can be done to make this easier ?
A lot. Intelligent completion can be done, so that if he types 
e.g.  "find_package(" the editor could suggest the existing cmake modules for 
completion. There can be wizards for creating configure tests ("which header 
do you want to check for ?") and then automatically create the cmake check 
and the config.h.in from it. This would be way more useful than trying to 
hide this from the developer.

So, please reconsider what you are doing, your time can be used MUCH better 
than reimplementing cmake.

Alex