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($)
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
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
