| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[llvm][cmake] Make install_symlink workflow work with absolute install dirs If CMAKE_INSTALL_BINDIR is a different absolute path per project, as it is with NixOS when we install every package to its own prefix, the old way fails when the absolute path gets prepended with CMAKE_INSTALL_PREFIX. The extend_path function does what we want, but it is currently internal-only. So easier to just inline the one small case of it we need. Also fix one stray bin -> CMAKE_INSTALL_BINDIR Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D101070 | 3 年前 | |
cmake: Avoid leading space in LLVM_DEFINITIONS. Summary: Unnecessary space at the beginning of LLVM_DEFINITIONS in cmake shared files can break projects that use the variable. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13432 llvm-svn: 250025 | 10 年前 | |
Add .cmt and .cmti files for OCaml bindings We can build .cmt and .cmti files for easier code navigation for OCaml bindings | 4 年前 | |
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181 | 4 年前 | |
[llvm] [cmake] Move LLVM_INSTALL_PACKAGE_DIR top-level to fix llvm-config Move the LLVM_INSTALL_PACKAGE_DIR declaration from llvm/cmake/modules directory to the top-level llvm/CMakeLists.txt, in order to fix the regression in llvm-config --cmakedir output for installed LLVM. Since the tools directory is processed by CMake prior to llvm/cmake/modules, the llvm-config executable ended up using the variable prior to it being defined and incorrectly used an empty path, resulting in e.g.: $ llvm-config --cmakedir /usr/lib/llvm/16/ With this patch, the path is defined (and therefore the default value is being set) prior to adding the tools subdirectory and llvm-config starts working correctly: $ llvm-config --cmakedir /usr/lib/llvm/16/lib64/cmake/llvm This fixes a regression introduced by D130539. Thanks to Petr Polezhaev for reporting the problem @ https://bugs.gentoo.org/865165 Differential Revision: https://reviews.llvm.org/D131878 (cherry picked from commit d230055234863aafe63489f9ab95e52d2c1883f2) | 3 年前 | |
[AIX][cmake] Set atomics related macros when build with xlclang Set HAVE_CXX_ATOMICS_WITHOUT_LIB or HAVE_LIBATOMIC when build LLVM with xlclang. With these macros set, libraries like libLLVMSupport are able to know whether it's necessary to add -latomic to dependent system libs. If HAVE_LIBATOMIC is set, llvm-config --system-libs appends -latomic to its output. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D111782 | 4 年前 | |
Bump minimum toolchain version RFC: https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm Following the policy here: https://llvm.org/docs/DeveloperPolicy.html#toolchain This forum post here will be updated with the timeline and status: https://discourse.llvm.org/t/important-new-toolchain-requirements-to-build-llvm-will-most-likely-be-landing-within-a-week-prepare-your-buildbots/61447 Reviewed By: mehdi_amini, jyknight, jhenderson, cor3ntin, MaskRay Differential Revision: https://reviews.llvm.org/D122976 | 4 年前 | |
[CMake] Check for problematic MSVC + /arch:AVX configuration Add a new CMake file to expand on for more problematic configurations in the future. Related to #54645 Reviewed By: beanz, phosek, smeenai Differential Revision: https://reviews.llvm.org/D123777 | 4 年前 | |
Revert r361826, as it still breaks LLDB. llvm-svn: 361837 | 7 年前 | |
[CMake] Add targets for generating coverage reports This is a pretty small bit of CMake goop to generate code coverage reports. I always forget the right script invocation and end up fumbling around too much. Wouldn't it be great to have targets that "Just Work"? Well, I thought so. At present this only really works correctly for LLVM, but I'll extend it in subsequent patches to work for subprojects. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D109019 | 4 年前 | |
[CMake] Don't pass CMAKE_C(XX)_COMPILER to the nested NATIVE build when cross compiling Originally, the nested build was set up with the CMake command execute_process which implicitly passes CC/CXX variables for the configured compiler, which then was picked up by the nested CMake. (This CMake behaviour, to implicitly pass such variables is up for discussion and might change in the future; see https://gitlab.kitware.com/cmake/cmake/-/issues/21378.) How the nested cmake build is set up was changed in aa7d6db5c8fc449b2908c6d629d6d9a067f49896 / D40229 - the old behaviour was brought along by manually passing -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} to the nested cmake configuration. This was then later made optional in f5f0fffea5ace079cc208fafa65150d23935a4d9 / D40947. But still, the default if the user doesn't pass CROSS_TOOLCHAIN_FLAGS_${target_name} (e.g. CROSS_TOOLCHAIN_FLAGS_NATIVE) is to pass in the surrounding build's compiler - which usually doesn't work, and is quite non-obvious to figure out. Just drop the default passing of the outer compiler, when cross compiling. This should avoid surprising cases of using the cross compiler for the native build for essentially all new users trying to cross compile, until they've discovered CROSS_TOOLCHAIN_FLAGS_NATIVE. Keep passing these when not cross compiling, e.g. if building with optimized tablegen. This was already suggested at the end in D40229, but apparently never acted upon. Differential Revision: https://reviews.llvm.org/D126313 | 4 年前 | |
CMake is funky on detecting Intel 17 as GCC compatible. Summary: This adds a fallback in case that the Intel compiler is failed to be detected correctly. Reviewers: chapuni Reviewed By: chapuni Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D27610 llvm-svn: 293230 | 9 年前 | |
[CMake] Installable find modules for terminfo and libffi Improves cross-distro portability of LLVM cmake package by resolving paths for terminfo and libffi via import targets. When LLVMExports.cmake is generated for installation, it contains absolute library paths which are likely to be a common cause of portability issues. To mitigate this, the discovery logic for these dependencies is refactored into find modules which get installed alongside LLVMConfig.cmake. The result is cleaner, cmake-friendly management of these dependencies that respect the environment of the LLVM package importer. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D114327 | 4 年前 | |
[CMake] Fix FindGRPC.cmake for setting up gRPC related libraries for macOS+homebrew context * Switch $GRPC_OPTS references to ${GRPC_OPTS} * Use target_include_directories() to add include search paths only for the targets the depend on gRPC * Also find and include the search path for abseil headers (gRPC headers include them) * Only setup the gRPC related targets once, so that include(FindGRPC) can be called from multiple tools Differential Revision: https://reviews.llvm.org/D127893 | 4 年前 | |
[llvm-exegesis] Check perf_branch_entry for field cycles Summary: Follow up to breakages reported in D77422 Reviewers: ondrasej, gchatelet Tags: #llvm Differential Revision: https://reviews.llvm.org/D84076 | 5 年前 | |
[OCaml] [cmake] Add CMake buildsystem for OCaml. Closes PR15325. llvm-svn: 223071 | 11 年前 | |
Add SPHINX_WARNINGS_AS_ERRORS CMake option to allow warnings to not be treated as errors (which is still the default). This is useful when working on documentation that has existing errors. llvm-svn: 215634 | 11 年前 | |
[CMake] Installable find modules for terminfo and libffi Improves cross-distro portability of LLVM cmake package by resolving paths for terminfo and libffi via import targets. When LLVMExports.cmake is generated for installation, it contains absolute library paths which are likely to be a common cause of portability issues. To mitigate this, the discovery logic for these dependencies is refactored into find modules which get installed alongside LLVMConfig.cmake. The result is cleaner, cmake-friendly management of these dependencies that respect the environment of the LLVM package importer. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D114327 | 4 年前 | |
Fix FindZ3.cmake to support static libraries and Windows Use absolute path to link z3 to allow builds both on windows and linux since the library name is platform dependent for Z3 (libz3 on Windows and z3 on Linux) and MSVC does not recognized -L and -l options. Fix CMAKE_CROSSCOMPILING that does not work correctly since it uses Z3_BUILD_VERSION instead of Z3_BUILD_NUMBER Fix building with the static version of z3 library (supersedes D80227). - Build the Z3 version detection code as C++, since the static library brings in libstdc++ symbols - Detect threading support and link against threading, in the (likely) case Z3 was built with threads Exposed compilation error from building a program that is used to detect z3 version in the warning message, to simplify troubleshooting. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D106131 | 4 年前 | |
[CMake] Provide Findzstd module This module is used to find the system zstd library. The imported targets intentionally use the same name as the generate zstd config CMake file so these can be used interchangeably. Differential Revision: https://reviews.llvm.org/D134990 (cherry picked from commit 2d4fd0b6d5d5582ebb8b521d807104235d67aee4) | 3 年前 | |
[llvm] [cmake] Use current directory in GenerateVersionFromVCS Find dependent scripts of GenerateVersionFromVCS in current directory rather than ../../cmake/modules. I do not see any reason why the former would not work and The latter is incorrect when GenerateVersionFromVCS is used from install directory (i.e. in stand-alone builds). Differential Revision: https://reviews.llvm.org/D57996 llvm-svn: 353674 | 7 年前 | |
[CMake] Add explicit return to GetErrcMessages test program | 4 年前 | |
[CMake] Make the vendor part of default mingw triples consistent Consistently use 'w64' as vendor string; it was 'pc' for the original i686 triple added in 91bd6c922d7cf, but the later x86_64 triple used 'w64' as vendor, added in d6c1f37f86440. When the arm triples were added in c84ad73a27da6, the differing vendors were copied over accidentally to the arm targets too. When using per-target runtime directories, having inconsistent vendor parts of the target triples is fatal. Differential Revision: https://reviews.llvm.org/D107894 | 4 年前 | |
[CMake] Simplify CMake handling for libxml2 This matches the changes made to handling of zlib done in 10b1b4a where we rely on find_package and the imported target rather than manually appending the library and include paths. The use of LLVM_LIBXML2_ENABLED has been replaced by LLVM_ENABLE_LIBXML2 thus reducing the number of variables. Differential Revision: https://reviews.llvm.org/D84563 | 5 年前 | |
Init project. | 11 个月前 | |
[CMake][llvm] avoid conflict w/ (and use when available) new builtin check_linker_flag Match the API for the new check_linker_flag and use it directly when available, leaving the old code as a fallback. Differential Revision: https://reviews.llvm.org/D100901 | 5 年前 | |
[llvmbuildectomy] Also include component groups in llvm-config --components list Without this change mesa fails while looking for llvm components like amdgpu, engine or native: Run-time dependency LLVM (modules: amdgpu(missing), bitreader, bitwriter, core, engine(missing), executionengine, instcombine, ipo, mcdisassembler, mcjit, native(missing), scalaropts, transformutils, coroutines) Looking for a fallback subproject for the dependency llvm (modules: bitwriter, engine, mcdisassembler, mcjit, core, executionengine, scalaropts, transformutils, instcombine, amdgpu, native, bitreader, ipo) This change adds component groups (like all-targets, engine, native, amdgpu) to the "all" component. Differential Revision: https://reviews.llvm.org/D92158 | 5 年前 | |
[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ to /lib/Target/. Differential Revision: https://reviews.llvm.org/D106775 | 4 年前 | |
[llvm][cmake] Shore up llvm_check_linker_flags. Ensure CMAKE_EXE_LINKER_FLAGS effects the underlying try_compile by setting this policy to use the new, non-deprecated behavior, without effecting the caller. Normally this shouldn't be necessary, as CMake uses cmake_minimum_required(VERSION 3.13.4) consistently, but I suppose this could rear its head in a downstream project? Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D118546 | 3 年前 | |
tweak zstd behavior in cmake and llvm config for better testing add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag (compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable) propagate variable zstd_DIR in LLVMConfig.cmake.in fix llvm-config CMakeLists.txt behavior for absolute libs windows get zstd lib name Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D132870 (cherry picked from commit c0b4f248df79f184adba856f13a950a53c881f3f) | 3 年前 | |
Revert "[CMake] Use write_basic_package_version_file for LLVM" This reverts commit 3001d080c813da20b329303bf8f45451480e5905 which seems to have introduced a race condition that's failing the build in some cases. | 5 年前 | |
[runtimes] Handle interface targets in runtimes distribution components As reported in [1], cxx-headers is not a valid distribution target because it is an interface target in CMake. This breaks the most basic MultiDistributionExample of the runtimes build. This patch handles interface targets by getting rid of the assumption that all distribution components have a target associated to them. It is valid for a distribution component to only have a install-FOO target. In the case where only cxx-headers is provided as a distribution component, ninja toolchain-distribution will not build anything after this patch, since there is effectively nothing to build for the cxx-headers target. However, running ninja install-toolchain-distribution will build everything, as expected. [1]: https://discord.com/channels/636084430946959380/636732894974312448/1010013287464828968 Differential Revision: https://reviews.llvm.org/D132387 (cherry picked from commit 5905e699342fd476d7eb9e35db5d84248a7e9156) | 3 年前 | |
cmake fill cmake_args when cross-compiling external project with non-clang compiler This makes it possible to crosscompile runtimes with cl.exe on Windows. An external project is completely misconfigured otherwise because cmake_args is set only for native builds or builds crosscompiled with clang. Differential Revision: https://reviews.llvm.org/D122578 Reviewed By: beanz, compnerd | 4 年前 | |
[llvm][cmake] Make install_symlink workflow work with absolute install dirs If CMAKE_INSTALL_BINDIR is a different absolute path per project, as it is with NixOS when we install every package to its own prefix, the old way fails when the absolute path gets prepended with CMAKE_INSTALL_PREFIX. The extend_path function does what we want, but it is currently internal-only. So easier to just inline the one small case of it we need. Also fix one stray bin -> CMAKE_INSTALL_BINDIR Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D101070 | 3 年前 | |
Init project. | 11 个月前 | |
[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 年前 | |
[mlgo] Don't provide default model URLs Pointed out in Issue #56432: the current reference models may not be quite friendly to open source projects. Their purpose is only illustrative - the expectation is that projects would train their own. To avoid unintentionally pulling such a model, made the URL cmake setting require explicit user setting. Differential Revision: https://reviews.llvm.org/D129342 | 3 年前 | |
[CMake] Use libtool for runtimes when building for Apple platform LLVM CMake build already uses libtool instead of ar when building for Apple platform and we should be using the same when building runtimes. To do so, this change extracts the logic for finding libtool into a separate file and then uses it from both the LLVM build as well as the LLVM runtimes build. Differential Revision: https://reviews.llvm.org/D62769 llvm-svn: 362313 | 7 年前 | |
Make ninja smart console builds more pretty Summary: CMake's find_package outputs to the console on success, which confuses the smart console mode of the ninja build system. Let's quiet the success message and manually warn instead. Reviewers: tstellar, phosek, mehdi_amini Reviewed By: mehdi_amini Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82276 | 5 年前 | |
[cmake] Export driver template to fix standalone build Export the driver-template.cpp.in file so that tools using GENERATE_DRIVER work in standalone builds (currently only relevant for clang). I've given the file an llvm- prefix, as we're now searching for the file in CMAKE_MODULE_PATH. Differential Revision: https://reviews.llvm.org/D127384 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 10 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 9 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 11 年前 | ||
| 11 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 11 个月前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 4 年前 |