KDE/kdevelop/languages/cpp

[Andreas Pakulat]

On 28.06.07 00:47:10, 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 ?

Lets put it this way: There are dozens of CMake*AST classes in the
CMakeLists parser, so if any of those is not fully supported thats a bug
our the cmake parser.

> ...
> > 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

Vladimir already said something about Boost. I don't know any of the
others but I think kdelibs is a pretty good testcase. Apart from that
there are already dozens of unittests written for the parser.

> > 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.

Hope you are aware that not everybody needs a portable buildsystem and
still have complex projects. There are things that just can't be ported
to other platforms, or maybe rather won't ever be ported.

Apart from that I'm with Matt here, unless cmake provides a library and
API to query it about the information its unavoidable to reimplement
cmake's logic in the KDevelop CMake support. Matt already tried to use
the generators and apparently it wasn't satisfying. 

Andreas

-- 
Your heart is pure, and your mind clear, and your soul devout.