Hello,<br><br>Thanks for the replies.<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Date: Tue, 30 Jan 2007 13:05:22 +0000<br>

From: Richard Dale <<a href="mailto:rdale@foton.es">rdale@foton.es</a>><br>Subject: Re: [Kde-bindings] first step of QT4 binding for Perl5<br>To: KDE bindings for other programming languages<br>        <<a href="mailto:kde-bindings@kde.org">

kde-bindings@kde.org</a>><br>Message-ID: <<a href="mailto:200701301305.22266.rdale@foton.es">200701301305.22266.rdale@foton.es</a>><br>Content-Type: text/plain;  charset="utf-8"<br><br>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.

<br>> the procedue in my mind is:<br>> 1) grab all required information directly from cpp headers and store them<br>> as YAML format as per<br>> file basis;<br>> 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.

<br>><br>> the idea is still rough. At this moment, I would like to discuss with you<br>> all, try to get other ideas.<br>><br>> just check out from <a href="https://dongxu.googlecode.com/svn/trunk/PerlQT">

https://dongxu.googlecode.com/svn/trunk/PerlQT</a><br>> The grammar is based on a famous parse module in Perl world -<br>> Parse::RecDescent. Differred<br>> from a formal compiler, it behaves a little bit fuzzy. Hope it works on

<br>> other release, since<br>> I am not very sure I've got all QT-specific macros.<br>><br>> instructions:<br>> $make gen_parse<br>> and coffee, it will walk through nearly over 700 files<br>><br>

> notes:<br>> 1) currently there is no proper parse result, I just print debug info into<br>> each YAML file,<br>>    just check the content in each of them;<br>> 2) unfortunately it only works on linux, GNU make and perl are required;

<br>><br>> todos:<br>>   pls pls feel free to give your idea/opinion on this tool, I do need some<br>> other things.<br>The current PerlQt 3.0 Smoke library is generated with a perl script which can<br>also parse all the Qt 

4.2.2 headers. It could certainly be better written,<br>and replacing it with another parser, such as your one might be a good idea.<br>I would personally like to use the KDevelop C++ parser in the future for<br>generating bindings, and other people think that using the gcc xmldump tool

<br>is the best way to do it.</blockquote><div><br>I am not very familiar with KDevelop C++ parser. <br>In my personal opinion, the best binding parsers should have:<br>1) the lowest maintainence effort, the changes appears in a source file could be 

<br>    grouped into two categories, language-specific syntax and tool-specific <br>    markup. Both C++ and gcc (or other compiler) are growing, introducing <br>    new syntax and idea with the time being. While the fundamental change on 

<br>    the tool-specific level is macro. that is the reason why even the KDevelop C++ <br>    parser needs to be taught on new macros.<br>    The works done by a compiler parser is quite different from my point of view.<br>

    It needs to identify every detail of a source, which means it works until the <br>    bottom level. While the information to make a binding is not so deep. The <br>    differences of goal will lead to differences in both maintainence and patch. 

<br>    That is why I assume we need a 'fuzzy' parser in this area.<br></div>2) the best format of result. I have different thought on the production of such a <br>    parser. What SMOKE products is programmatic data dictionary. That is fine 

<br>    for immediate compile and link. There is no readability then. Although <br>    currently I still have no clear sight, in order to apply new functionality, <br>    for instance, as mentioned, the class inheritance info, it is neccessary to patch 

<br>    the result of parser. That is the main reason I plan to take YAML as the result <br>    format, for both human readability and manual patch.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

The parsing is only a small part of a bindings project, and by far the hardest<br>bit is deciding what code to generate. I think the way the Smoke library<br>works is very hard to beat, as it is the only library for language bindings

<br>that can work with more than one language (ie perl, ruby, c# and php<br>currently). So I'm more interested in helping to design a better version of<br>Smoke, which perhaps would use some of the way the Qt 4 moc generated code

<br>works, but allowing for multiple inheritance and generating code for every<br>method in every class and not just slots in QObject subclasses.</blockquote><div><br>sure, that is main reason I  dropped such post here. You guys have rich experience 

<br>on both QT and interface design. I do need to learn new ideas from you all ;-)<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

-- Richard<br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 30 Jan 2007 15:52:01 +0100 (MET)<br>From: Arno Rehn <<a href="mailto:arno@arnorehn.de">arno@arnorehn.de</a>><br>Subject: Re: [Kde-bindings] first step of QT4 binding for Perl5

<br>To: KDE bindings for other programming languages<br>        <<a href="mailto:kde-bindings@kde.org">kde-bindings@kde.org</a>><br>Message-ID: <<a href="mailto:200701301552.00096.arno@arnorehn.de">200701301552.00096.arno@arnorehn.de

</a>><br>Content-Type: text/plain;  charset="iso-8859-1"<br><br><br>I've recently talked to a Mono SWF developer and he suggested to generate<br>bindings with SWIG ( <a href="http://www.swig.org/">http://www.swig.org/

</a> ). 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.

<br>At the moment I'm very satisfied with SMOKE :-)</blockquote><div><br>SWIG is quite nice on making generic bindings, but as I said, just generic ones.<br> For different dynamic language, what should be considered is, how to best fit 

<br>the popular program semantics/pratice introduced by that language. For <br>instance, in Perl, people will perfer operate on tied magical variable rather than <br>raw data container. There are language specific part that swig could not handle 

<br>properly at this moment. One of the main reasons why people choose binding <br>instead of original c library is definitely here. Well, I indeed saw something nice <br>made by swig on CPAN ;-)<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

--<br>Arno Rehn<br><a href="mailto:arno@arnorehn.de">arno@arnorehn.de</a></blockquote><div><br>cheers,  <br></div><br></div>