[all-commits] [llvm/llvm-project] 08bfed: [mlir] Add option to disable MLIR Python dev packa...

[Stella Laurenzo via All-commits]

  Branch: refs/heads/users/stellaraccident/mlir_cmake_optional_configure_python
  Home:   https://github.com/llvm/llvm-project
  Commit: 08bfedea7d3653c39eec86165b9c03fafb07d157
      https://github.com/llvm/llvm-project/commit/08bfedea7d3653c39eec86165b9c03fafb07d157
  Author: Stella Laurenzo <stellaraccident at gmail.com>
  Date:   2024-11-27 (Wed, 27 Nov 2024)

  Changed paths:
    M mlir/CMakeLists.txt
    M mlir/cmake/modules/MLIRDetectPythonEnv.cmake

  Log Message:
  -----------
  [mlir] Add option to disable MLIR Python dev package configuration.

Adds a CMake option MLIR_CONFIGURE_PYTHON_DEV_PACKAGES which gates doing package discovery and configuration for Python dev packages by MLIR.

The default Python setup that MLIR does has been a problem for super-projects that include LLVM for a long time because it forces a very specific package discovery mechanism that is not uniform in all uses.

When reviewing #117922, I noted that this would effectively be a break the world event for downstreams, forcing them to adapt their nanobind dep to the exact way that MLIR does it. Adding the option to just wholesale skip the built-in configuration heuristics at least gives us a mechanism to tell downstreams to migrate to, giving them complete control and not requiring packaging workarounds. This seemed a better option than (once again) creating a situation where downstreams could not integrate the dep change without doing tricky infra upgrades, and it removes the burden from the author of that patch from needing to think about how this affects super-projects that include MLIR (i.e. they can just be told to do it themselves as needed vs being in a wedged state and unable to upgrade).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications