More automated interfacing of D with C codebases

[Jacob Carlborg]

On 2012-10-22 19:27, timotheecour wrote:
>> SWIG requires some kind of interface files, which I assume one must
>> have to manually write. Then what's the difference?
>
> These can be as small as:
>
>
> sfml.i:
> %{
> #include <SFML/Audio.hpp>
> %}
> %include SFML/Config.hpp
> %include SFML/Audio/Export.hpp
>
> In practice, some additional tweaks may be needed to support certain
> constructs like multiple inheritance, etc, but nothing daunting (~ 50
> lines of code for my sfml interface file)
>
>> I don't think SWIG is the right approach because:
>> * You have to create these interface files
>
> =>
> see above. Interface files can be very small.
>
>> * It seem to not handle all code
> I was still able to port large libraries like sfml and opencv, using
> tweaks to the interface files and enhancing swig to support C++template
> to D template conversion. There's a small number of cases where swig
> currently chokes, some of which could be easily fixed if there's enough
> demand.
>
>> * No support for Objective-C
>
> =>
> http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
> One of SWIG's most recent additions is support for Objective-C parsing.
> This is currently an experimental feature that may be improved in future
> releases.
>
>> BTW, how does SWIG handle macros and documentation?
> You'd have to write a C/C++ function that does what the macro does in
> the interface file, which would in turn be converted to a D function.
>
> For exporting C documentation to D, I've asked on stackoverflow:
> http://stackoverflow.com/questions/12413957/export-comments-in-swig-wrapper
> I'm not sure it's supported ATM, but that's definitely something
> possible since swig has a full blown C++ parser.

Ok, I see.

If SWIG has a full blown C++ parser, then why is it choking on some 
code? Or does it need a semantic analyzer as well.

-- 
/Jacob Carlborg