llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/cmake/modules/NpcompDetectPythonEnv.cmake

30 lines
1.3 KiB
CMake
Raw Normal View History

Bump llvm-project to f4f8a67aaf13bc66a2b7d55561b14a3724a5e0de. * Incorporates source fixes. * Uses upstream pybind11 detection logic. * Patches CI. * This may break the CI, which will need to be fixed manually in a followup.
2020-11-23 05:01:15 +08:00
# Forked and adapted from MLIRDetectPythonEnv.cmake upstream. The eventual
# goal is to use the upstream configuration but until that is ready, just
# move/adapt these facilities. Please try to not diverge.
# Macros and functions related to detecting details of the Python environment.
# Detects a pybind11 package installed in the current python environment
# and sets variables to allow it to be found. This allows pybind11 to be
# installed via pip, which typically yields a much more recent version than
# the OS install, which will be available otherwise.
function(npcomp_detect_pybind11_install)
if(pybind11_DIR)
message(STATUS "Using explicit pybind11 cmake directory: ${pybind11_DIR} (-Dpybind11_DIR to change)")
else()
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
message(STATUS "Checking for pybind11 in python path...")
Bump llvm-project to f4f8a67aaf13bc66a2b7d55561b14a3724a5e0de. * Incorporates source fixes. * Uses upstream pybind11 detection logic. * Patches CI. * This may break the CI, which will need to be fixed manually in a followup.
2020-11-23 05:01:15 +08:00
execute_process(
Bump LLVM version to 4f5355ee73626f8b8fe6bf0dd6d167fea7628a2c. * Incorporates changes around LLVM StringRef. * Ports fix in upstream pybind11 detection. * Disables CI hack due to broken pybind detection.
2020-11-25 05:10:27 +08:00
COMMAND "${Python3_EXECUTABLE}"
Bump llvm-project to f4f8a67aaf13bc66a2b7d55561b14a3724a5e0de. * Incorporates source fixes. * Uses upstream pybind11 detection logic. * Patches CI. * This may break the CI, which will need to be fixed manually in a followup.
2020-11-23 05:01:15 +08:00
-c "import pybind11;print(pybind11.get_cmake_dir(), end='')"
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
RESULT_VARIABLE STATUS
OUTPUT_VARIABLE PACKAGE_DIR
ERROR_QUIET)
if(NOT STATUS EQUAL "0")
message(CHECK_FAIL "not found (install via 'pip install pybind11' or set pybind11_DIR)")
return()
endif()
set(pybind11_DIR "${PACKAGE_DIR}" PARENT_SCOPE)
endif()
endfunction()