llvm-d

[Moritz Maxeiner]

On Thursday, 4 April 2013 at 18:31:59 UTC, deadalnix wrote:
> 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.

For the internal C bindings I'll stick with the CTFE (although 
I'll try to minimize/optimize its use). For the deimos-llvm pull 
request I used CTFE as well, but Jens already said that he thinks 
it's more natural to use multiple branches for supporting 
different LLVM versions (See here: 
https://github.com/jkm/deimos-llvm/pull/2) and llvm-d now 
supports using deimos-llvm as a replacement for its internal C 
bindings, so if the CTFE is a serious problem for someone, using 
deimos-llvm once he has integrated the split the CTFE into the 
branches would be the best option, I think.

>
>> 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.

At present not yet, but since all LLVM C API functions wrap 
around LLVM's C++ class functions (except a few globals, which 
wrap around C++ globals) afaik to mimic as much of the LLVM 
hierarchy as possible, all these wrapper functions will be 
needed. I'll only be able to tell for sure once I'm finished, 
though and judging be the amount of work left that's going to 
take a while.

>
>> 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.

I'm not quite sure where you'd use an automated tool here that 
needs to be aware of any translation from C to D but if you do 
why not change the tool to make it aware of the 
constant/type/functions approach - It's not something I invented 
or actually new, see Derelict for example...

In any case, if you really need that, go with the deimos-llvm 
bindings. All you have to do is use "-version=DEIMOS_LLVM" and 
the internal C bindings won't even be imported by the D API and 
subsequently don't have to be compiled.