View mode: basic / threaded / horizontal-split · Log in · Help
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 04:34, Andrej Mitrovic wrote:
> On 3/17/12, Brad Anderson<eco@gnuk.net>  wrote:
>> Could the wxc generator be be used as a base for building bindings for
>> other libraries?
>
> I hope it will be. It's kind of crazy that the first thing I'm using
> it on is a huge library like wxD, this will likely be its biggest
> unittest, so to speak. :p
>
> Doxygen can be run on libraries with no documentation (there's a
> switch for that), so it can extract the needed data for the generator.
> Of course it depends how complex the library is, e.g. you can't run
> doxygen directly on wxWidgets include files because they're very
> complicated (it actually crashes doxygen), but this is why the wx devs
> have created a separate set of interface files for doxygen.

This is why a proper compiler is needed, this will not work in the long run.

-- 
/Jacob Carlborg
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 09:50 AM, Jacob Carlborg wrote:
> This is why a proper compiler is needed, this will not work in the long
> run.

Are you aware that doxgen's xml output is based on gcc-xml ?

I think it is necessary to say that doxygen, respective gcc-xml, is 
working on stripped and annotated header files (so called interface files)
f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/

So, stupid manual work is needed to create these interface files.

Until you don't have a heavily templated c++ lib, using doygen's xml 
output is, IMHO, a reasonable way to create bindings.

well, will see
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 18:36, bls wrote:
> On 03/17/2012 09:50 AM, Jacob Carlborg wrote:
>> This is why a proper compiler is needed, this will not work in the long
>> run.
>
> Are you aware that doxgen's xml output is based on gcc-xml ?

No, I was not aware of that. What is the problem then, doxygen choking 
on the XML or GCC choking on the include files?

> I think it is necessary to say that doxygen, respective gcc-xml, is
> working on stripped and annotated header files (so called interface files)
> f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/
>
> So, stupid manual work is needed to create these interface files.

That sucks.

-- 
/Jacob Carlborg
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:44 AM, Jacob Carlborg wrote:
> On 2012-03-17 18:36, bls wrote:
>> On 03/17/2012 09:50 AM, Jacob Carlborg wrote:
>>> This is why a proper compiler is needed, this will not work in the long
>>> run.
>>
>> Are you aware that doxgen's xml output is based on gcc-xml ?
>
> No, I was not aware of that. What is the problem then, doxygen choking
> on the XML or GCC choking on the include files?
>
>> I think it is necessary to say that doxygen, respective gcc-xml, is
>> working on stripped and annotated header files (so called interface
>> files)
>> f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/
>>
>> So, stupid manual work is needed to create these interface files.
>
> That sucks.
>
 Yeah it sucks, but on the other hand it is AFAIK just removing the 
private stuff (methods, decls,  etc.) forward decls, and write some 
annotations.. like @iOS-only from the header.

I really hope to see a working wxD soon. I will try to create bindings 
for the wxShapeFramework than..
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:44 AM, Jacob Carlborg wrote:
> What is the problem then, doxygen choking on the XML or GCC choking on
> the include files?

gcc-xml is stalled. Means newer C++ stuff is not supported.

See news...
http://www.gccxml.org/HTML/News.html
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:51 AM, bls wrote:
>> Are you aware that doxgen's xml output is based on gcc-xml ?

I should be more carefull :( It's another wxWidgets utility that is 
using gcc-xml.
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 3/17/12, Jacob Carlborg <doob@me.com> wrote:
> This is why a proper compiler is needed, this will not work in the long run.

The generator doesn't really care which tool you use to extract the
data. It should be possible to use a tool such as LLVM to fill the
structs with all the information it needs to build the wrappers. So in
essence it works in a similar way as your dstep project, although I
don't really know how far you've gone in implementing dstep so I can't
compare the two.
March 17, 2012
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 20:20, Andrej Mitrovic wrote:
> On 3/17/12, Jacob Carlborg<doob@me.com>  wrote:
>> This is why a proper compiler is needed, this will not work in the long run.
>
> The generator doesn't really care which tool you use to extract the
> data. It should be possible to use a tool such as LLVM to fill the
> structs with all the information it needs to build the wrappers. So in
> essence it works in a similar way as your dstep project, although I
> don't really know how far you've gone in implementing dstep so I can't
> compare the two.

Not ready for a comparison yet.

-- 
/Jacob Carlborg
May 21, 2012
Re: wxD bindings
On Sun, 12 Feb 2012 12:09:54 +0100
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

Hello Andrej,

> They have a tool called ifacecheck which compares the xml files
> generated by doxygen to the ones generated by using gccxml. I've used
> gccxml before. I haven't used ifacecheck yet but I'll give it a run.

just wonder if there are any news in regard to wxD bindings project?


Sincerely,
Gour

-- 
Even if you are considered to be the most sinful of all sinners, 
when you are situated in the boat of transcendental knowledge 
you will be able to cross over the ocean of miseries.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
May 28, 2012
Re: wxD bindings
On 5/21/12, Gour <gour@atmarama.net> wrote:
> just wonder if there are any news in regard to wxD bindings project?

I was busy doing another rewrite of my codebase since it was getting
rather large and too specific for wxwidgets (lots and lots of doxygen
workarounds). Doxygen files for handwritten interfaces are full of
missing information so this wasn't going anywhere (I've made about 65
fixes myself but this was already getting tiring
http://trac.wxwidgets.org/query?reporter=drey&order=priority).

So right now I'm writing a generic C++ wrapper generator, not specific
to wxwidgets. I can still extract type info from doxygen xml (as long
as the xml was generated from actual header files unlike in
wxwidgets), but I've also added support for gccxml (the cvs version is
mostly up-to-date and it actually works for wxWidgets). I should be
able to add support for clang later on, by outputting its typeinfo to
xml.

Right now I'm finishing work on adding support for C++ POD types,
which includes a feature to work around Issue 5570
(http://d.puremagic.com/issues/show_bug.cgi?id=5570) and another
feature that works around field-alignment mismatches between
languages. I've recently implemented a simple virtual-method
cross-language override mechanism that should probably be faster than
what swig provides, but I haven't done any performance testing yet
(there's no runtime checks at class construction, no extra boolean
fields and runtime checks or function pointers involved, which is what
swig uses with its "directors" feature).

Since I've made the codegen generic enough it should be possible to
output swig interface files instead of directly generating code. I'll
experiment with this once I'm done with my own codegen feature.

Anyway I really have no idea whether I'll have wxWidgets bindings any
time soon but I think I'll put the code generator online in a few
weeks. The latest rewrite I did has put my progress back by a long
time but it's better this way since the codebase is much cleaner and
properly documented right now. At least now I have actual test-cases
and I can compile and link generated code and do simple tests to see
if the generated code works properly.

Work is still in progress, need more time!
4 5 6 7 8 9
Top | Discussion index | About this forum | D home