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.

Reply via email to