Update LLVM version #43
Conversation
Move Clang down a level to make room for a new layer of abstraction built on top of Clang
Now that c.rb is empty we can put c_ffi.rb there.
|
Hey @neelance, is this something you would want to merge? I ended up cleaning and restructuring the code a lot before I got the gem working so this PR has ended up being quite large. If you think this PR changes too much I can just fork the gem. It was kind of a chicken and egg problem because I assumed I could not get the gem working until I updated its Clang FFI bindings to be compatible with a current version of Clang, but I needed the gem working to regenerate the bindings. |
I was struggling to use this gem as the target LLVM version was too old and it was failing when I tried to to use a recent version of LLVM.
I updated it to use the dynamic library of llvm-15. It would be nice to let this gem support whatever version of LLVM is installed but I don't think the
ffigem can currently support that, so I locked it to llvm-15.I refactored the code a bunch to try to figure out how it worked and then diagnose why it was not working with the recent version of LLVM. I managed to get it working again.
I found out that the Clang API should have been backward compatible from llvm-3.5 so I am not exactly sure what I did to fix the gem but it was working by the time I finished refactoring it.
I was not able to run most of the tests as those dynamic libraries are also too old to easily install.
I was able to get it to successfully regenerate its own Clang binding file. The "Update llvm/clang version" commit shows the changes to this file. I don't see any unexpected differences to it, just some things that have been cleaned up or added to the Clang header files since llvm-3.5. I was then able to use the new bindings to regenerate the file again and confirmed no changes to it this time.
I also added a quickstart guide to help people install LLVM.
Let me know what you think.