[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: [Kde-bindings] Common work for Qt4 bindings
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2005-09-13 11:48:39
Message-ID: 200509131348.39876.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Tuesday 13 September 2005 14:34, Eric Jardim wrote:
> 2005/9/13, Richard Dale <Richard_Dale@tipitina.demon.co.uk>:
> > I would expect so, but I'm not sure if it will have a full pre-processor.
>
> Why not? It would be nice to have introspectable information about signals,
> slots, properties. Think how this would help KDE development. Think about
> refactoring, too.
Yes, it will have that. But if you run source through the standard C++ 
pre-processor you lose information that you need for purposes like KDevelop 
or bindings generation, such as comments and obviously C macros as they 
looked before expansion (that's how a programmer using an IDE sees macros). 

> As far as I know it is going well. Maybe it is complete enough to do
>
> > bindings
> > experiments already (we need a complete symbol table and tree walking
> > api).
> > It is discussed on the kdevelop-devel@kdevelop.org list.
>
> We could ask him to not develop a KDE dependent parser. A nice and complete
> C++ parser for general purpose is a great achieve to the free software
> community.
It will be general purpose and not-KDE specific, but different to a parser you 
would have in a complete C++ compiler. For instance, with code completion, it 
must be faster than gcc and only parse incremental changes as you edit the 
source.

-- Richard

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]