KDE/kdevelop/languages/cpp

[Matt Rogers]

On Jun 27, 2007, at 11:47 PM, Alexander Neundorf wrote:

> On Thursday 28 June 2007 00:09, Matt Rogers wrote:
>> On Jun 27, 2007, at 9:44 PM, Alexander Neundorf wrote:
>
>>> 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
>
> Just that I don't misunderstand, are you going to reimplement all  
> that or just
> ignore it ?
>

Everything will be reimplemented. We have ASTs for every built-in  
command currently available in the CMake built-in language and will  
have support for macros and other extensions as well. See  
CMakeAst.cpp in buildtools/managers/cmake/parser for a nifty list.

> ...
>> 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
>
> In order to do this please use existing cmake projects as test cases:
> Paraview, kdelibs, Chicken Scheme, Boost, OpenWengo
>

That's what I was planning. Anything that I can find that uses CMake,  
I plan to test against it.

>> because I did it this way, since people won't have to spend so much
>> time editing CMakeLists.txt files.
>
> If they don't spend time thinking about the buildsystem it just  
> won't be
> portable. If it won't be portable having a simple project type  
> which will
> just work and also not be portable is just as good.
>
> Alex

It's certainly a possibility, but how can whoever is developing CMake  
support be held responsible for the fact that a buildsystem is not  
cross platform? Expecting that is unrealistic.
--
Matt