Skip to content

Define Python_FIND_VIRTUALENV in addition to Python3_FIND_VIRTUALENV #4004

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dbabokin
Copy link
Contributor

@dbabokin dbabokin commented Feb 7, 2025

MLIR searches for both Python3 and Python. If both variables are not defined equally and there multiple python versions on the system, CMake may behave really weirdly.

More details here: llvm/llvm-project#126162

So I grepped for all instances of Python3_FIND_VIRTUALENV and added similar Python_FIND_VIRTUALENV definition.

@dbabokin
Copy link
Contributor Author

dbabokin commented Feb 8, 2025

The fails in the CI are unrelated to the changes in this PR and they show up in other PR as well.

MLIR searches for both Python3 and Python. If both variables are not
defined equally and there multiple python version on the system, CMake
may behave really weirdly.

More details here: llvm/llvm-project#126162
@dbabokin
Copy link
Contributor Author

All green. Need someone to review and approve.

@marbre
Copy link
Member

marbre commented Apr 30, 2025

Thanks @dbabokin! Can you resolve the conflicts thus we can merge this? I guess we could also set the one option based on the other a little deeper in CMake world? But this also works for me.

@marbre marbre requested review from marbre and ScottTodd April 30, 2025 13:20
Comment on lines 63 to +64
-DPython3_FIND_VIRTUALENV=ONLY \
-DPython_FIND_VIRTUALENV=ONLY \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MLIR searches for both Python3 and Python. If both variables are not defined equally and there multiple python versions on the system, CMake may behave really weirdly.

Could MLIR use IREE's approach instead? https://github.com/iree-org/iree/blob/fd74b8829bebb9c64d45d265d906dbc7b0301c40/CMakeLists.txt#L654-L663

if(IREE_BUILD_PYTHON_BINDINGS)
  # ...
  find_package(Python3 3.9 COMPONENTS Interpreter Development NumPy)
  find_package(Python3 3.9 COMPONENTS Interpreter Development.Module NumPy REQUIRED)
  # Some parts of the build use FindPython instead of FindPython3. Why? No
  # one knows, but they are different. So make sure to bootstrap this one too.
  # Not doing this here risks them diverging, which on multi-Python systems,
  # can be troublesome. Note that nanobind requires FindPython.
  set(Python_EXECUTABLE "${Python3_EXECUTABLE}")
  find_package(Python 3.9 COMPONENTS Interpreter Development.Module NumPy REQUIRED)
elseif(IREE_BUILD_COMPILER OR IREE_BUILD_TESTS)
  find_package(Python3 COMPONENTS Interpreter REQUIRED)
  set(Python_EXECUTABLE "${Python3_EXECUTABLE}")
  find_package(Python COMPONENTS Interpreter REQUIRED)
endif()

That's been working well for us, and it's less configuration needed by the user. One small bandaid in the build system is fine with me... but this starts to spread extra arguments across scripts and documentation too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants