On 2012-10-21 21:45, timotheecour wrote:
Manually porting of C/C++ libraries shouldn't be the way to go (a major problem being when said library gets updated, human errors, porting to different architectures etc).
SWIG requires some kind of interface files, which I assume one must have to manually write. Then what's the difference?
I've had good experience using SWIG to automate the job for me, and used it successfully to port the following libraries to D: * ncurses * opencv * sfml to name a few. I believe this is the way forward, as opposed to maintaining (necessary stale) ports such as Deimos. Swig isn't perfect however, and sometimes will bail out on constructs such as: C++ classes with multiple inheritance, or a few obscure C or C++ constructs. Even in that case, I find it much easier to tweak the swig interface file to get desired output rather than undertake the huge manual conversion task. For sfml, the interface file is just about 40 lines for example. Improving such kind of automated tools is where we should be concentrating efforts, not on maintaining deimos. One such improvement I made was to allow conversion of C++ templates to D templates (works in large majority of cases), which makes the library much easier to use than using name mangling schemes. More improvements would be welcome (eg support for static library generation as opposed to dynamic load libraries), reducing the need for tweaking swig interface files etc.
I don't think SWIG is the right approach because: * You have to create these interface files * It seem to not handle all code * No support for Objective-C BTW, how does SWIG handle macros and documentation? -- /Jacob Carlborg
