MoritzMaxeiner/llvm-d

Newer versions

Dmunch04 opened this issue · 9 comments

Dmunch04 commented

Hi!

Are there any plans to support newer versions of LLVM? Specifically I'm hoping for v10.0.1, but even v9 would be great.

foerdi commented

Hi,

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

Dmunch04 commented

@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 commented

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 commented

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 commented

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 commented

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 commented

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 commented

Nice, Thank you.

I hope I can test it next weekend.