llvm-d

[deadalnix]

On Friday, 29 March 2013 at 12:07:11 UTC, Moritz Maxeiner wrote:
> Now regarding the fact that you say that solution will have the 
> negative side-effect of making compile time and resource 
> "explode": I have tested llvm-d on some of my old machines 
> (inluding a first-gen intel atom underclocked to about 800 Mhz) 
> and llvm-d compilation was never noticable slow, or used 
> considerable memory. But to either prove or contradict whether 
> this is a noticable side-effect of that solution we'd need hard 
> benchmarks.
>

DMD uses an huge amount of resource for CTFE, and leak a LOT of 
memory. That is already known. Obviously, compiling this lib by 
itself isn't going to trigger such issue.

> See here under "Enumerations":
> http://llvm.org/docs/doxygen/html/group__LLVMCCoreTypes.html
>
> The enums documentation would not match the enums anymore, as 
> the items' names would be different (even if it is just missing 
> the part about their enum's name).
>

It would simply transform LLVMXXXYYY into LLVMXXX.YYY, which is 
simply a workaround C limitations in the first place.

> Another reason why the C bindings' enums and the D bindings' 
> enums will stay seperated is for compatibility with 
> deimos-llvm, which will be usable as a replacement for the 
> internal C bindings for people who e.g. want a c header -> d 
> module translation.

You thrown away that with your module refactoring, so it is kind 
of pointless to raise that point now.