JJohn Ericson[cmake] Don't export LLVM_TOOLS_INSTALL_DIR anymore
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 年前 | |
[mlir][Tablegen-LSP] Add support for a basic TableGen language server This follows the same general structure of the MLIR and PDLL language servers. This commits adds the basic functionality for setting up the server, and initially only supports providing diagnostics. Followon commits will build out more comprehensive behavior. Realistically this should eventually live in llvm/, but building in MLIR is an easier initial step given that: * All of the necessary LSP functionality is already here * It allows for proving out useful language features (e.g. compilation databases) without affecting wider scale tablegen users * MLIR has a vscode extension that can immediately take advantage of it Differential Revision: https://reviews.llvm.org/D125440 | 4 年前 |