llvm-d

[deadalnix]

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.