[Kde-bindings] Refactoring kalyptus
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Wed Dec 7 16:21:08 UTC 2005
On Wednesday 07 December 2005 14:10, Caleb Tennis wrote:
> Hi,
>
> I know there was some thoughts and talk about 6 months ago on smoke
> refactoring and reworking for the Qt4 bindings. One thought I had on the
> subject was to use gcc's preprocessor dump to handle the #defines and
> #ifdef stuff that kalyptus tries cleverly to muddle through.
>
> It looks like just doing a "gcc -E" on a header file, provided all of the
> #includes are met, will preprocess the file automagically. This might cut
> down on some of the ambiguity and overhead that smoke and kalyptus go
> through.
>
> Anyone have thoughts on this? Am I way off on my thinking?
I think the problem is that sometimes you want the macros before they are
pre-processed, and you also want to be able to get the comments for language
bindings. For instance, I convert the KDE C++ style doc comments to javadoc
ones for the KDE java bindings, and I'd like to convert them to RDOC ones for
ruby. Another possibility is to use the xml format produced by the gcc
translation unit dump. The disadvantages of that are that it is gcc specific,
and so I think you would need to generate the bindings and check the
generated code into the svn - it couldn't be generated by the 'make' command
as the Smoke lib is now.
I think my personal 'plan A' for a better C++ parser would be to use the one
that Roberto Raggi is developing for KDevelop 4/KDE 4. That is what Trolltech
are using for their Qt4 java bindings, although I don't know anything else
about their approach as they're doing it 'behind closed doors' as a
commercial product (although I assume will also be GPL'd). I'll cc this to
the kdevelop-devel list as I regard language bindings work as part of
creating RAD environments, and they aren't much use without suitable IDE's to
go with them, and there are C++ parsing issues that the projects have in
common.
As well as a parser for bindings generation, you need to build a symbol table,
and you need a means of transforming the abstract syntax tree from the parser
in powerful ways. People underestimate how difficult it is to write a C++
parser, as well as not realising it is only solves about 25% of the technical
problem is producing language bindings. Hence, the very few successful
efforts to produce complete, finished Qt/KDE bindings..
-- Richard
More information about the KDevelop-devel
mailing list