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

[Arno Rehn]

Am Dienstag, 30. Januar 2007 14:05 schrieb 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.

I've recently talked to a Mono SWF developer and he suggested to generate 
bindings with SWIG ( http://www.swig.org/ ). I've only taken a quick glance 
at it, but from what I've seen it could be useful. Maybe this could be an 
alternative to the SMOKE library, even though I don't know how to handle 
signal/slots or marshalling with SWIG.
At the moment I'm very satisfied with SMOKE :-)

-- 
Arno Rehn
arno at arnorehn.de