On Jun 27, 2007, at 9:44 PM, Alexander Neundorf wrote:
> 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
I'm so tired of discussing my approach to supporting CMake
in
KDevelop. Nobody is bitching at the QMake folks because
they're
parsing .pro files. Nobody will be bitching at me for
parsing the
autotools files. So why are you bitching at me for parsing
CMake files?
The CMake folks won't export an API for us to use and using
a
generator just will not provide the integration that I want
to
provide KDevelop's users. You can't use a generator to edit
CMakeLists.txt files from a GUI. I won't explain any more to
you
again what I want to do. You already know what it is.
Claiming that
it can't be done just makes me want to do it even more.
Having a neat
editor with autocompletion for CMakeLists.txt file just will
not do.
Having a neat editor provided with CMake that KDevelop can
somehow
load (like a plugin) doesn't work either since CMake won't
move away
from it's command-based infrastructure and so having that
editor
which is provided by CMake is basically impossible. And you
know
what, I've accepted the current reality and my inability to
change
it, so you should also accept the current reality and your
inability
to change it. Yeah, parts of CMake are being re-implemented.
I'm sure
it'll turn out just fine and we'll all be happier in the
long run
because I did it this way, since people won't have to spend
so much
time editing CMakeLists.txt files.
It's time to just agree to disagree and be done with it. I'm
not
budging, and at this point, you will now be talking into
thin air and
wasting your own time writing any further emails on the
subject.
--
Matt
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
