You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make LLVM_VERSION configurable with env variable #138497
Right now the LLVM version used is hardcoded in _llvm.py file.
The version could be override using environment variables so downstream builders can choose a different version to build against when enabling experimental JIT.
I'm honestly on the fence about this. I agree that we should only officially support one version at a time, but in practice a few downstream distributors seem to be patching the LLVM version (either using a newer version on an older Python or an older version on a newer Python).
Allowing the officially supported version to be overridden with an env var is probably okay, provided it's clear that we don't support any version other than the default. Like CFLAGS_JIT, this should probably be captured at configure-time and passed to the build script rather than discovered by the build script itself.
I arrive late to the party but wouldn't it also be useful if we could specify a path to a LLVM installation? There might be different cases for that:
pass different installations of the same version of LLVM (useful for development). Instead of doing the trick with paths, we point to the installation directory of llvm and it will be using that.
pass different versions of LLVM. Case is similar to the one of this issue but instead passing a number we pass the path.
this doesn't replace the LLVM_VERSION but could be another way to specify what llvm to use.
I arrive late to the party but wouldn't it also be useful if we could specify a path to a LLVM installation? There might be different cases for that:
* pass different installations of the same version of LLVM (useful for development). Instead of doing the trick with paths, we point to the installation directory of llvm and it will be using that.
* pass different versions of LLVM. Case is similar to the one of this issue but instead passing a number we pass the path.
this doesn't replace the LLVM_VERSION but could be another way to specify what llvm to use.
There's a different PR to support custom LLVM installation path: #138452
Activity
sobolevn commentedon Sep 4, 2025
I think that this can lead to a problem that people will supply versions of LLVM that are not supported.
Fidget-Spinner commentedon Sep 4, 2025
Yeah we don't guarantee that we can build with a range of LLVM versions, only a specific one for the JIT.
brandtbucher commentedon Sep 8, 2025
I'm honestly on the fence about this. I agree that we should only officially support one version at a time, but in practice a few downstream distributors seem to be patching the LLVM version (either using a newer version on an older Python or an older version on a newer Python).
Allowing the officially supported version to be overridden with an env var is probably okay, provided it's clear that we don't support any version other than the default. Like
CFLAGS_JIT, this should probably be captured atconfigure-time and passed to the build script rather than discovered by the build script itself.diegorusso commentedon Sep 26, 2025
I arrive late to the party but wouldn't it also be useful if we could specify a path to a LLVM installation? There might be different cases for that:
this doesn't replace the LLVM_VERSION but could be another way to specify what llvm to use.
danigm commentedon Sep 29, 2025
There's a different PR to support custom LLVM installation path: #138452
gh-138497: Support LLVM_VERSION configuration via env (#138498)