Thread overview
Automatic binding generation
Jan 06, 2012
Piotr Szturmaj
Jan 06, 2012
Trass3r
Jan 06, 2012
Jacob Carlborg
Jan 07, 2012
Trass3r
Jan 07, 2012
Jacob Carlborg
Jan 19, 2013
MrOrdinaire
Jan 19, 2013
Jacob Carlborg
Jan 19, 2013
Jacob Carlborg
Jan 06, 2012
bls
January 06, 2012
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
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
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
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
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
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
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
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
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