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

[Dongxu Ma]

Hello,

Thanks for the replies.


> Date: Tue, 30 Jan 2007 13:05:22 +0000
> From: Richard Dale <rdale at foton.es>
> Subject: Re: [Kde-bindings] first step of QT4 binding for Perl5
> To: KDE bindings for other programming languages
>         <kde-bindings at kde.org>
> Message-ID: <200701301305.22266.rdale at foton.es>
> Content-Type: text/plain;  charset="utf-8"
>
> 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.


I am not very familiar with KDevelop C++ parser.
In my personal opinion, the best binding parsers should have:
1) the lowest maintainence effort, the changes appears in a source file
could be
    grouped into two categories, language-specific syntax and tool-specific
    markup. Both C++ and gcc (or other compiler) are growing, introducing
    new syntax and idea with the time being. While the fundamental change on

    the tool-specific level is macro. that is the reason why even the
KDevelop C++
    parser needs to be taught on new macros.
    The works done by a compiler parser is quite different from my point of
view.
    It needs to identify every detail of a source, which means it works
until the
    bottom level. While the information to make a binding is not so deep.
The
    differences of goal will lead to differences in both maintainence and
patch.
    That is why I assume we need a 'fuzzy' parser in this area.
2) the best format of result. I have different thought on the production of
such a
    parser. What SMOKE products is programmatic data dictionary. That is
fine
    for immediate compile and link. There is no readability then. Although
    currently I still have no clear sight, in order to apply new
functionality,
    for instance, as mentioned, the class inheritance info, it is neccessary
to patch
    the result of parser. That is the main reason I plan to take YAML as the
result
    format, for both human readability and manual patch.

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.


sure, that is main reason I  dropped such post here. You guys have rich
experience
on both QT and interface design. I do need to learn new ideas from you all
;-)

-- Richard
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Jan 2007 15:52:01 +0100 (MET)
> From: Arno Rehn <arno at arnorehn.de>
> Subject: Re: [Kde-bindings] first step of QT4 binding for Perl5
> To: KDE bindings for other programming languages
>         <kde-bindings at kde.org>
> Message-ID: <200701301552.00096.arno at arnorehn.de>
> Content-Type: text/plain;  charset="iso-8859-1"
>
>
> 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 :-)


SWIG is quite nice on making generic bindings, but as I said, just generic
ones.
 For different dynamic language, what should be considered is, how to best
fit
the popular program semantics/pratice introduced by that language. For
instance, in Perl, people will perfer operate on tied magical variable
rather than
raw data container. There are language specific part that swig could not
handle
properly at this moment. One of the main reasons why people choose binding
instead of original c library is definitely here. Well, I indeed saw
something nice
made by swig on CPAN ;-)

--
> Arno Rehn
> arno at arnorehn.de


cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20070131/7aa6a2cf/attachment.html>