KDE/kdevelop/languages/cpp
Alexander Neundorf
neundorf at kde.org
Thu Jun 28 02:44:33 UTC 2007
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
More information about the KDevelop-devel
mailing list