Selecting LLVM versions with Cargo features
This issue follows from discussion in this Inkwell issue.
Crates that depend on llvm-sys
currently can't use feature switches to let their own users choose an LLVM version. This is due to a limitation of Cargo: although you could have feature switches to select different versions of llvm-sys
to depend on, Cargo will throw an error because you have potentially multiple dependencies that both want to link against LLVM, and Cargo always assumes that features are additive - all features could be enabled at once. Cargo isn't sophisticated enough (currently) to reason about mutually exclusive features when building its dependency graph, even if you have custom logic in your own crate to throw a compile-time error if incompatible features are selected.
This means that other crates using llvm-sys
who want to publish to crates.io currently have to choose a single LLVM version for each crates.io release. This applies to Inkwell itself, to my crate llvm-ir
, and to all other users of llvm-sys
, Inkwell, or llvm-ir
. It doesn't necessarily make sense to force all of these other crates to adopt a crates.io version numbering scheme like llvm-sys
's in order to support multiple LLVM versions - they have their own version numberings based on their own development progress.
One solution to this problem would be for llvm-sys
to provide its own feature switches to choose an LLVM version, rather than have a separate crates.io release and Git branch for each LLVM version. As a proof of concept (and temporary workaround for my own crates), I recently created llvm-sys-featured
, a fork of llvm-sys
which essentially combines llvm-sys
80.2.0, 90.1.0, and 100.1.1 into a single Git branch and crates.io release, allowing users to choose between the three versions with a Cargo feature. I plan to use this for the upcoming 0.7.0 release of llvm-ir
, so that that release can support multiple LLVM versions based on feature flags.
Are you interested in this being upstreamed? It would probably be a lot of work to combine all LLVM versions back to 3.6 in a single version, but maybe llvm-sys
could consider keeping its branch model for older LLVM versions and having a single branch for LLVM 8, 9, 10, and moving forward. (Or adding LLVM 7 might not be that much work if someone was interested and thought it would be helpful.) If you're willing to consider a PR, I'm happy to open one.
Thanks for all your work on llvm-sys
!