Description

danigm

opened on Sep 4, 2025

Issue body actions

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.

Linked PRs

• gh-138497: Support LLVM_VERSION configuration via env #138498

Activity

1. sobolevn

   added

   type-featureA feature request or enhancementA feature request or enhancement

   buildThe build process and cross-buildThe build process and cross-build

   on Sep 4, 2025
2. sobolevn commented on Sep 4, 2025

   

   sobolevn

   on Sep 4, 2025

   Member

   More actions

   I think that this can lead to a problem that people will supply versions of LLVM that are not supported.
3. StanFromIreland

   added

   topic-JIT

   on Sep 4, 2025
4. Fidget-Spinner commented on Sep 4, 2025

   

   Fidget-Spinner

   on Sep 4, 2025

   Member

   More actions

   Yeah we don't guarantee that we can build with a range of LLVM versions, only a specific one for the JIT.
5. brandtbucher commented on Sep 8, 2025

   

   brandtbucher

   on Sep 8, 2025

   Member

   More actions

   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.
6. diegorusso commented on Sep 26, 2025

   

   diegorusso

   on Sep 26, 2025

   Contributor

   More actions

   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.
7. danigm commented on Sep 29, 2025

   

   danigm

   on Sep 29, 2025

   ContributorAuthor

   More actions

   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

   Reacted by Diego Russo and Savannah Ostrowski
8. savannahostrowski

   added a commit that references this issue on Oct 7, 2025

   gh-138497: Support LLVM_VERSION configuration via env (#138498)

   96c59a6
9. savannahostrowski

   closed this as completedon Oct 7, 2025

Issue actions