View mode: basic / threaded / horizontal-split · Log in · Help
January 06, 2012
Automatic binding generation
Is should be possible to use debug info of a library to generate D or 
other language bindings. Current approaches are SWIG, htod and/or manual 
coding. The first two do not always work as expected (try using them to 
make OpenCV bindings) as parser-based converters do not always support 
all build environment details. Often, you need a fully capable C/C++ 
compiler to correctly parse headers.

Function information may be extracted from:

* PDB files using DIA SDK on Windows
* DWARF info using libdwarf or libdw on *nixes

Debug files contain information about functions, their argument types 
and return types, about structs and classes/namespaces (C++). Recent 
version of DWARF may even contain information about macros.

The usual binding creation would be simple:

1. build library using existing build environment with debug info
2. run converter to generate D bindings (this may be used to make C#'s 
bindings as well)

Thanks to the 1st point we can avoid many incompatibilities with 
SWIG/htod parsers as we get all symbols in one file. The whole process 
may be automated in most circumstances. Eventually some fixup files may 
be used to assist with conversion (similar to SWIG files, but without 
enumerating everything).

Thoughts?
January 06, 2012
Re: Automatic binding generation
What you will get is completely platform-dependent.

The only proper solution is using something like clang to write a 
C++->D converter.
First only headers, later source code.
January 06, 2012
Re: Automatic binding generation
On 01/06/2012 12:34 PM, Piotr Szturmaj wrote:
> Is should be possible to use debug info of a library to generate D or
> other language bindings. Current approaches are SWIG, htod and/or manual
> coding. The first two do not always work as expected (try using them to
> make OpenCV bindings) as parser-based converters do not always support
> all build environment details. Often, you need a fully capable C/C++
> compiler to correctly parse headers.
>
> Function information may be extracted from:
>
> * PDB files using DIA SDK on Windows
> * DWARF info using libdwarf or libdw on *nixes
>
> Debug files contain information about functions, their argument types
> and return types, about structs and classes/namespaces (C++). Recent
> version of DWARF may even contain information about macros.
>
> The usual binding creation would be simple:
>
> 1. build library using existing build environment with debug info
> 2. run converter to generate D bindings (this may be used to make C#'s
> bindings as well)
>
> Thanks to the 1st point we can avoid many incompatibilities with
> SWIG/htod parsers as we get all symbols in one file. The whole process
> may be automated in most circumstances. Eventually some fixup files may
> be used to assist with conversion (similar to SWIG files, but without
> enumerating everything).
>
> Thoughts?

Sure,  not exactly what you have in mind, but at least an exotic thought
Source commenting -> Doxygen XML output -> XML to D.

This is not as obscure as one might think, F.I. - GCCXML based bindings. 
- Ages ago I've  talked with Frank (keinfarbton) about using Java2XML to 
automate SWT porting...
January 06, 2012
Re: Automatic binding generation
On 2012-01-06 21:51, Trass3r wrote:
> What you will get is completely platform-dependent.
>
> The only proper solution is using something like clang to write a C++->D
> converter.
> First only headers, later source code.

I'm working on that, slowly.

-- 
/Jacob Carlborg
January 07, 2012
Re: Automatic binding generation
On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
> On 2012-01-06 21:51, Trass3r wrote:
>> The only proper solution is using something like clang to 
>> write a C++->D
>> converter.
>> First only headers, later source code.
>
> I'm working on that, slowly.

btw, I wonder if it's all that good to do that as a clang fork.
You will merge upstream from time to time and their countless 
commits will clutter the history, so it becomes hard to find out 
what really belongs to your tool.
Also it shouldn't be a modified clang executable with a new 
-rewrite option anyway. One doesn't want nor need a full 
compiler. no codegen, no countless cmdline options (just some 
like -I etc.).
January 07, 2012
Re: Automatic binding generation
On 2012-01-07 10:31, Trass3r wrote:
> On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
>> On 2012-01-06 21:51, Trass3r wrote:
>>> The only proper solution is using something like clang to write a C++->D
>>> converter.
>>> First only headers, later source code.
>>
>> I'm working on that, slowly.
>
> btw, I wonder if it's all that good to do that as a clang fork.
> You will merge upstream from time to time and their countless commits
> will clutter the history, so it becomes hard to find out what really
> belongs to your tool.
> Also it shouldn't be a modified clang executable with a new -rewrite
> option anyway. One doesn't want nor need a full compiler. no codegen, no
> countless cmdline options (just some like -I etc.).

I'm rewriting it using the Clang C bindings, using Clang as a library. 
I'm just hoping I will be able to do all the things I need to do with 
the C bindings.

-- 
/Jacob Carlborg
January 19, 2013
Re: Automatic binding generation
On Saturday, 7 January 2012 at 14:05:57 UTC, Jacob Carlborg wrote:
> On 2012-01-07 10:31, Trass3r wrote:
>> On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg 
>> wrote:
>>> On 2012-01-06 21:51, Trass3r wrote:
>>>> The only proper solution is using something like clang to 
>>>> write a C++->D
>>>> converter.
>>>> First only headers, later source code.
>>>
>>> I'm working on that, slowly.
>>
>> btw, I wonder if it's all that good to do that as a clang fork.
>> You will merge upstream from time to time and their countless 
>> commits
>> will clutter the history, so it becomes hard to find out what 
>> really
>> belongs to your tool.
>> Also it shouldn't be a modified clang executable with a new 
>> -rewrite
>> option anyway. One doesn't want nor need a full compiler. no 
>> codegen, no
>> countless cmdline options (just some like -I etc.).
>
> I'm rewriting it using the Clang C bindings, using Clang as a 
> library. I'm just hoping I will be able to do all the things I 
> need to do with the C bindings.

May I ask what is the status of this project? Manually writing
bindings is error-prone and no fun at all.
January 19, 2013
Re: Automatic binding generation
On 2013-01-19 03:03, MrOrdinaire wrote:

> May I ask what is the status of this project? Manually writing
> bindings is error-prone and no fun at all.

It's working for all C constructs. I have mad one release. What it 
cannot handle is the preprocessor. And it doesn't handle includes very 
well. It can only handle one file at the time. Except from that it's 
working pretty good.

https://github.com/jacob-carlborg/dstep

There's binaries for Mac OS X and Linux:

https://github.com/jacob-carlborg/dstep/downloads

-- 
/Jacob Carlborg
January 19, 2013
Re: Automatic binding generation
On 2013-01-19 15:48, Jacob Carlborg wrote:

> There's binaries for Mac OS X and Linux:
>
> https://github.com/jacob-carlborg/dstep/downloads

I haven't been able to link it on Windows due to optlink not willing to 
cooperate.

-- 
/Jacob Carlborg
Top | Discussion index | About this forum | D home