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.
