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.
