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

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

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

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..

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

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.

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.

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

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

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!