Newer versions about llvm-d

[MoritzMaxeiner]

Pull requests welcome.

[foerdi]

Hi,

is anyone already working on this?
I am also interested in v10, I can make a merge request in the near future.

[Dmunch04]

@foerdi
I'm working on my own bindings lib for v10 specifically. I don't know if it's planned for llvm-d tho

[MoritzMaxeiner]

is anyone already working on this?

Not that I'm aware of.

I am also interested in v10, I can make a merge request in the near future.

Thanks :)

[MoritzMaxeiner]

I'm working on my own bindings lib for v10 specifically. I don't know if it's planned for llvm-d tho

I'm curious, is there anything in llvm-d's design that isn't suited to your use case? Adding new LLVM support to llvm-d isn't inherently difficult, you just have to do a diff between two LLVM tarballs' llvm-c include directory and translate those changes to D. I'll happily merge a good PR, but I myself just have no need for a new version.

[Dmunch04]

Mostly because it's my first time wrapping extern libs to D. I wasn't sure how I would do so, so I decided to try it out "privately". And then I also find the llvm-d structure a bit confusing

[MoritzMaxeiner]

And then I also find the llvm-d structure a bit confusing

I see. FWIW:

llvm/config.d: Version definition and target support (targets are what LLVM calls its backends)
llvm/constants.d: Enumerations and other constants
llvm/types.d: Type definitions
llvm/functions/link.d: Function stubs

Adding a new LLVM version usually only needs to touch those files.

[MoritzMaxeiner]

I hadn't planned on it, but since I had some free time I added on-paper support for 9.0.0, 9.0.1, and 10.0.0.

Please test @Dmunch04 @foerdi.

[foerdi]

Nice, Thank you.

I hope I can test it next weekend.