KDE/kdevelop/languages/cpp

[Alexander Neundorf]

Hi,

Von: Andreas Pakulat <apaku at gmx.de>

> On 28.06.07 00:47:10, Alexander Neundorf wrote:
> > 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.

Ok, you are going to reimplement it.

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

This wasn't meant as a critic. There are other complex cmake based projects outthere, so it would be a good idea to use them as testcases for the cmake support in kdevelop. You have to make sure that it is possible to modify the buildsystem of these projects with the cmake support in kdevelop without breaking the build for these projects on any platform.

Yes, cmake is not the official buildsystem of Boost.
Currently there are some people trying to build Boost with cmake, and since they are doing it in a quite different way than we do in KDE, it would be a good test case:
https://svn.boost.org/svn/boost/sandbox/troy/boost_1_34_0

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

Most of the commands also need to implement the logic, otherwise the results will be wrong.
 
> > > 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

With portable I don't necessarily mean portable to Windows or OSX, just portable to other UNIXes as FreeBSD or even just to other Linux distributions.

> 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

I don't know what you want to achieve. All the commercial IDEs (MSVC, XCode, Keil, ...) where you can setup the build with a GUI are *by far* not as powerful as what you can do with autotools/cmake/scons. I don't see the point in trying to put all this power into a GUI.
If you get this working, this would be great, but I just can't image how this should work. 

Alex

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer