With the release of LLVM 3.8, there have been some backwards-incompatible changes to the C API that
llvm-sys binds to. Since the C API can change in incompatible ways across LLVM versions, I would like to make a way for
llvm-sys to enforce that a compatible C API is used.
My initial feeling is that the crate’s own version number should indicate the target version of LLVM, such that
llvm-sys ~3.7 enforces that the version of LLVM in use is part of the 3.7 series. This allows easy tracking of version requirements, but could complicate setup for users of the library.
To avoid forcing users to be careful about what version of LLVM they have avaliable when building applications that use
llvm-sys, I have two ideas right now:
- Add support for downloading and compiling a copy of LLVM matching the version of
llvm-sysin use. This is not a small download, nor is it quick to compile. It does however allow a user to skip any LLVM setup on their system, which is especially useful for platforms where there are no LLVM library binaries available (like Windows). Failures could be difficult to debug for users.
- Have a database available at build-time tracking which functions are available for a given version of LLVM, so
llvm-syscan cause a compile-time error if a user attempts to use a function which is known to be unsupported with the linked version of LLVM. This would likely require build-time code generation for the bindings, and could be confusing since functions could appear in documentation which are not available, with no capability to provide a very meaningful error message.
So, I’m interested to hear what others think about this problem. Do you think version pinning is important? Which approach (or one of your own) to easing the pain do you think is nicer, or is it not a concern?