SSebastian Neubauer[CMake] Fix add_subdirectory llvm builds
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[cmake] Don't export LLVM_TOOLS_INSTALL_DIR anymore First of all, LLVM_TOOLS_INSTALL_DIR put there breaks our NixOS builds, because LLVM_TOOLS_INSTALL_DIR defined the same as CMAKE_INSTALL_BINDIR becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that LLVM_TOOLS_INSTALL_DIR stands out against the other specially crafted LLVM_CONFIG_* variables substituted in llvm/cmake/modules/LLVMConfig.cmake.in. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in AddLLVM, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which LLVMConfig.cmake is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many ${project}_TOOLS_INSTALL_DIRs. AddLLVM now instead expects each project to define its own, and they do so based on CMAKE_INSTALL_BINDIR. LLVMConfig still exports LLVM_TOOLS_BINARY_DIR which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the AddLLVM changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977 | 3 年前 | |
Restore Python install behavior from before D128230. In D128230, we accidentally moved the install for Python sources outside of the loop, having one install() per group of files. While it would be nice if we could do this, it means that we flatten the relative directory tree and every source ends up in the root. The right way to do this is to use FILE_SETS, which preserve the relative directory tree, but they are not available until CMake 3.23. Differential Revision: https://reviews.llvm.org/D129434 | 3 年前 | |
[CMake] Fix add_subdirectory llvm builds Fixes a regression from D117973, that used CMAKE_BINARY_DIR instead of LLVM_BINARY_DIR in some places. Differential Revision: https://reviews.llvm.org/D130555 | 3 年前 | |
[mlir][PDLL] Add support for generating PDL patterns from PDLL at build time This essentially sets up mlir-pdll to function in a similar manner to mlir-tblgen. Aside from the boilerplate of configuring CMake and setting up a basic initial test, two new options are added to mlir-pdll to mirror options provided by tblgen: * -d This option generates a dependency file (i.e. a set of build time dependencies) while processing the input file. * --write-if-changed This option only writes to the output file if the data would have changed, which for the build system prevents unnecesarry rebuilds if the file was touched but not actually changed. Differential Revision: https://reviews.llvm.org/D124075 | 4 年前 | |
[mlir] Update Python CMake version requirement. The minimum required version is now 3.19 due to the usage of some more recent features. Update the version check and error message accordingly. Also remove some logic that behaved differently before 3.18, since we can assume we are now on version 3.19+. Reviewed By: stella.stamenova Differential Revision: https://reviews.llvm.org/D130171 | 3 年前 |