KDE/kdevelop/languages/cpp

Matt Rogers mattr at kde.org
Thu Jun 28 04:09:32 UTC 2007


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(${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

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






More information about the KDevelop-devel mailing list