On Tuesday, 2 April 2013 at 15:30:53 UTC, Moritz Maxeiner wrote:
I've not seen any mention about that under the "Documentation" category and I've only found posts about that after explicitly searching for that problem right now. I'm sorry for not knowing about that, but if that is such a critical problem, it may be sensible to document it in an article, e.g. "Compile time function evaluation", under dlang.org's "Documentation" category - I expected dmd to not use more memory for CTFE operations than D would for runtime operations.
I'd prefers see the problem fixed than documented. Anyway it is real, and should be considered now.
Regardless of that, the llvm-d's D API will need to include all of the C API bindings anyway (however they may be done) and llvm-d's internal C bindings exist primarily for the use of the D API. If you only want the C bindings anyway, consider using deimos-llvm. I've forked it and am going to update it to 3.2 and 3.3svn: https://github.com/Calrama/deimos-llvm
I don't think all modules need to, but you know better than me.
I don't use C header -> D module in llvm-d's internal C bindings, llvm-d's D API, however, can use either llvm-d's internal C bindings or (soon) deimos-llvm. I do not consider it pointless to raise the point that if you (the user, not you specifically) want to have a C header -> D module translation you can use deimos-llvm together with llvm-d's D API without llvm'd internal C bindings, that's all.
The thing is that any automated tool will suffer from the translated module name as it cannot transform #include directives.
