[Kde-bindings] first step of QT4 binding for Perl5

[Richard Dale]

On Tuesday 30 January 2007, Dongxu Ma wrote:
> Hi All,
>
> some information. I wrote a tool to extract all proto/typedef/enum/class
> from all QT cpp headers.
> Yesterday it passed all files in v 4.2.2 release.
> This is the first step I am thinking about to make a new PerlQT binding.
> the procedue in my mind is:
> 1) grab all required information directly from cpp headers and store them
> as YAML format as per
> file basis;
> 2) define an interface policy to determine which one to export and which
> one not; or possibly arrange
>     an abstract API layer to wrap some interface changes;
> 3) manally write a typedef for all involved type/class(s);
> 4) generate stubs;
> 5) compile and link.
>
> the idea is still rough. At this moment, I would like to discuss with you
> all, try to get other ideas.
>
> just check out from https://dongxu.googlecode.com/svn/trunk/PerlQT
> The grammar is based on a famous parse module in Perl world -
> Parse::RecDescent. Differred
> from a formal compiler, it behaves a little bit fuzzy. Hope it works on
> other release, since
> I am not very sure I've got all QT-specific macros.
>
> instructions:
> $make gen_parse
> and coffee, it will walk through nearly over 700 files
>
> notes:
> 1) currently there is no proper parse result, I just print debug info into
> each YAML file,
>    just check the content in each of them;
> 2) unfortunately it only works on linux, GNU make and perl are required;
>
> todos:
>   pls pls feel free to give your idea/opinion on this tool, I do need some
> other things.
The current PerlQt 3.0 Smoke library is generated with a perl script which can 
also parse all the Qt 4.2.2 headers. It could certainly be better written, 
and replacing it with another parser, such as your one might be a good idea. 
I would personally like to use the KDevelop C++ parser in the future for 
generating bindings, and other people think that using the gcc xmldump tool 
is the best way to do it.

The parsing is only a small part of a bindings project, and by far the hardest 
bit is deciding what code to generate. I think the way the Smoke library 
works is very hard to beat, as it is the only library for language bindings 
that can work with more than one language (ie perl, ruby, c# and php 
currently). So I'm more interested in helping to design a better version of 
Smoke, which perhaps would use some of the way the Qt 4 moc generated code 
works, but allowing for multiple inheritance and generating code for every 
method in every class and not just slots in QObject subclasses.

-- Richard