aboutsummaryrefslogtreecommitdiff
path: root/clang/cmake/modules
AgeCommit message (Collapse)AuthorFilesLines
2023-01-13[cmake] Fix path to LLVMConfig.cmake for multi-config buildsNhat Nguyen1-1/+2
D139623 replaces CMAKE_CFG_INTDIR with '.' for multi-config builds. However, this change has not been reflected in mlir, flang, polly, lld, and clang. The patch updates the path to LLVMConfig.cmake for those projects. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D141538
2023-01-12Revert "build: with -DCLANGD_ENABLE_REMOTE=ON, search for grpc++ ↵Kadir Cetinkaya1-6/+1
dependencies too" This reverts commit 9f3081dc6fe8447e85741865846840bc491866e5. Broke clangd buildbots in https://lab.llvm.org/buildbot/#/builders/131/builds/38935.
2023-01-10build: with -DCLANGD_ENABLE_REMOTE=ON, search for grpc++ dependencies tooSylvestre Ledru1-1/+6
Fixes: https://github.com/llvm/llvm-project/issues/59844 Differential Revision: https://reviews.llvm.org/D141047
2022-11-25Add version to all LLVM cmake packageThomas Preud'homme3-1/+24
Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident, mceier Differential Revision: https://reviews.llvm.org/D138274
2022-11-25Revert: Add version to all LLVM cmake packageThomas Preud'homme3-24/+1
Summary: This reverts commit ad485b71b51168ce13282ae159bd8feff48baf84. Reviewers: Subscribers:
2022-11-20Add version to all LLVM cmake packageThomas Preud'homme3-1/+24
Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident Differential Revision: https://reviews.llvm.org/D138274
2022-10-25[clang] Replace BACKEND_PACKAGE_STRING with LLVM_VERSION_STRINGFangrui Song1-1/+1
420d7ccbac0f499a6ff9595bdbfa99cd3376df22 introduced BACKEND_PACKAGE_STRING to replace `PACKAGE_VERSION` (llvm/Config/config.h) to support standalone builds. This is used in the output of `clang -cc1 -v`. Since llvm-config.h is available for both standalone and non-standalone builds, we can just use `LLVM_VERSION_STRING` from llvm-config.h. clang/cmake/modules/AddClang.cmake uses `VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})"`. Just simplify it to `"${CLANG_VERSION}"` so that we can remove the CMake variable BACKEND_PACKAGE_STRING. Reviewed By: tstellar Differential Revision: https://reviews.llvm.org/D136660
2022-10-12[CMake] Fix FindGRPC cmake module to allow different layeringSteven Wu1-0/+11
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Fixes: https://github.com/llvm/llvm-project/issues/58075 Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D135712
2022-10-01[llvm-driver] Support single distributionsAlex Brachet1-2/+8
`LLVM_DISTRIBUTION_COMPONENTS` now influences the llvm binary in the normal cmake output directory when it is set. This allows for distribution targets to only include tools they want in the llvm binary. It must be done this way because only one target can be associated with a specific output name. Differential Revision: https://reviews.llvm.org/D131310
2022-10-01[llvm-driver][NFC] Simplify handling of tool symlinksAlex Brachet1-1/+1
Differential Revision: https://reviews.llvm.org/D134979
2022-09-14[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson1-1/+1
better-suited, part 2 A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is. This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
2022-09-10[clang][cmake] Remove extra braceMohammed Keyvanzadeh1-1/+1
Remove the extra trailing brace from the local variable accessor. Differential Revision: https://reviews.llvm.org/D133613
2022-08-25Revert "[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable ↵John Ericson1-1/+1
are better-suited" This reverts commit ad8c34bc3089d847a09bb740f7a58c96073e0959.
2022-08-24[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson1-1/+1
better-suited A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `compiler-rt/cmake/Modules/CompilerRTUtils.cmake - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
2022-08-18Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too"John Ericson2-4/+4
This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18[cmake] Use `CMAKE_INSTALL_LIBDIR` tooJohn Ericson2-4/+4
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it. Now we return this. `LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set `CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed entirely. I imagine this is too potentially-breaking to make LLVM 15. That's fine. I have a more minimal version of this in the disto (NixOS) patches for LLVM 15 (like previous versions). This more expansive version I will test harder after the release is cut. Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D130586
2022-08-04Reland "[lldb/Fuzzer] Add fuzzer for expression evaluator"Chelsea Cassanova1-1/+5
This reverts commit d959324e1efec12c3924c17b7d90db0b37eb84c3. The target_include_directories in the clang-fuzzer CMake files are set to PRIVATE instead of PUBLIC to prevent the clang buildbots from breaking when symlinking clang into llvm. The expression evaluator fuzzer itself has been modified to prevent a bug that occurs when running it without a target.
2022-07-25[cmake] Support custom package install pathsJohn Ericson1-6/+11
Firstly, we we make an additional GNUInstallDirs-style variable. With NixOS, for example, this is crucial as we want those to go in `${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir of the "regular" libdir, which is installed even when no one needs to do any development. Secondly, we make *Config.cmake robust to absolute package install paths. We for NixOS will in fact be passing them absolute paths to make the `${dev}` vs `${out}` distinction mentioned above, and the GNUInstallDirs-style variables are suposed to support absolute paths in general so it's good practice besides the NixOS use-case. Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other install dirs are. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D117973
2022-07-25[CMake] Copy folder without permissionsSebastian Neubauer1-1/+2
Copying the folder keeps the original permissions by default. This creates problems when the source folder is read-only, e.g. in a packaging environment. Then, the copied folder in the build directory is read-only as well. Later on, other files are copied into that directory (in the build tree), failing when the directory is read-only. Fix that problem by copying the folder without keeping the original permissions. Follow-up to D130254. Differential Revision: https://reviews.llvm.org/D130338
2022-07-22Revert "[lldb/Fuzzer] Add fuzzer for expression evaluator"Med Ismail Bennani1-5/+1
This reverts commit b797834748f1954950880bf50fb78abedd4494e6, since it breaks building Clang: https://reviews.llvm.org/D129377
2022-07-22[lldb/Fuzzer] Add fuzzer for expression evaluatorChelsea Cassanova1-1/+5
This commit adds a fuzzer for LLDB's expression evaluator. The fuzzer takes a different approach than the current fuzzers present, and uses an approach that is currently being used for clang fuzzers. Instead of fuzzing the evaluator with randomly mutated characters, protobufs are used to generate a subset of C++. This is then converted to valid C++ code and sent to the expression evaluator. In addition, libprotobuf_mutator is used to mutate the fuzzer's inputs from valid C++ code to valid C++ code, rather than mutating from valid code to total nonsense. Differential revision: https://reviews.llvm.org/D129377
2022-07-22[CMake][Clang] Copy folder without permissionsSebastian Neubauer1-0/+2
Copying the folder keeps the original permissions by default. This creates problems when the source folder is read-only, e.g. in a packaging environment. Then, the copied folder in the build directory is read-only as well. Later on, with configure_file, ClangConfig.cmake is copied into that directory (in the build tree), failing when the directory is read-only. Fix that problem by copying the folder without keeping the original permissions. Differential Revision: https://reviews.llvm.org/D130254
2022-07-21[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreJohn Ericson1-2/+2
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_DIR`s. `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
2022-07-20[llvm-driver] Generate symlinks instead of executables for toolsAlex Brachet1-23/+40
When LLVM_TOOL_LLVM_DRIVER_BUILD is On, create symlinks to llvm instead of creating the executables. Currently this only works for install and not install-distribution, the work for the later will be split up into a second patch. Differential Revision: https://reviews.llvm.org/D127800
2022-06-10Revert "[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore"John Ericson1-2/+2
This reverts commit d5daa5c5b091cafb9b7ffd19b5dfa2daadef3229.
2022-06-10[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreJohn Ericson1-2/+2
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_DIR`s. `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
2022-06-06LLVM Driver Multicall toolChris Bieneman1-0/+3
This patch adds an llvm-driver multicall tool that can combine multiple LLVM-based tools. The build infrastructure is enabled for a tool by adding the GENERATE_DRIVER option to the add_llvm_executable CMake call, and changing the tool's main function to a canonicalized tool_name_main format (i.e. llvm_ar_main, clang_main, etc...). As currently implemented llvm-driver contains dsymutil, llvm-ar, llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the build). llvm-driver can be enabled from builds by setting LLVM_TOOL_LLVM_DRIVER_BUILD=On. There are several limitations in the current implementation, which can be addressed in subsequent patches: (1) the multicall binary cannot currently properly handle multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver will not properly result in llvm-ar's main being called. (2) the multicall binary cannot be comprised of tools containing conflicting cl::opt options as the global cl::opt option list cannot contain duplicates. These limitations can be addressed in subsequent patches. Differential revision: https://reviews.llvm.org/D109977
2022-01-21[clang][cmake] Use `GNUInstallDirs` to support custom installation dirsJohn Ericson2-3/+6
I am breaking apart D99484 so the cause of build failures is easier to understand. Differential Revision: https://reviews.llvm.org/D117419
2022-01-16Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson1-3/+2
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have this odd error, not sure how to reproduce, so I will just try breaking up my patch. This reverts commit 4a678f8072004eff9214c1a4e1836a14abb69535.
2022-01-16[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson1-2/+3
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2022-01-15Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson1-3/+2
Sorry for the disruption, I will try again later. This reverts commit efeb50197091b2ade24c00b9d55814bc433a7fd1.
2022-01-15[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson1-2/+3
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2022-01-12[Clang] Make Clang copy its CMake modules into the build dirAndrzej Warzynski1-0/+8
LLVM has a documented mechanism for passing configuration information to an out of tree project using CMake. See https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project. Similar logic applies to "standalone" builds of other sub-projects within LLVM that depend on each other. For example, a standalone build of Flang will use this mechanism to acquire Clang's configuration. Currently, the relevant CMake modules for Clang will only be copied into the installation directory. This means that in order to configure a standalone build of Flang, one has to first build and then install Clang. This is not required for LLVM nor for MLIR - other sub-projects that Flang depends on (i.e. the CMake modules for LLVM and MLIR are available in the build dir, so installation is not needed). This change removes the need for installing Clang in order to access its configuration. It makes sure that the required CMake modules are copied into the build directory. This will make Clang behave consistently with LLVM and MLIR in this respect. It will also simplify building Flang as standalone sub-project. Differential Revision: https://reviews.llvm.org/D116731
2022-01-07[CMake] Factor out config prefix finding logicJohn Ericson1-10/+2
See the docs in the new function for details. I think I found every instance of this copy pasted code. Polly could also use it, but currently does something different, so I will save the behavior change for a future revision. We get the shared, non-installed CMake modules following the pattern established in D116472. It might be good to have LLD and Flang also use this, but that would be a functional change and so I leave it as future work. Reviewed By: beanz, lebedev.ri Differential Revision: https://reviews.llvm.org/D116521
2021-09-20Revert "Fix CLANG_ENABLE_STATIC_ANALYZER=OFF building all analyzer source"Nico Weber1-10/+2
This reverts commit 6d7b3d6b3a8dbd62650b6c3dae1fe904a8ae9048. Breaks running cmake with `-DCLANG_ENABLE_STATIC_ANALYZER=OFF` without turning off CLANG_TIDY_ENABLE_STATIC_ANALYZER. See comments on https://reviews.llvm.org/D109611 for details.
2021-09-20Fix CLANG_ENABLE_STATIC_ANALYZER=OFF building all analyzer sourceAlex Richardson1-2/+10
Since https://reviews.llvm.org/D87118, the StaticAnalyzer directory is added unconditionally. In theory this should not cause the static analyzer sources to be built unless they are referenced by another target. However, the clang-cpp target (defined in clang/tools/clang-shlib) uses the CLANG_STATIC_LIBS global property to determine which libraries need to be included. To solve this issue, this patch avoids adding libraries to that property if EXCLUDE_FROM_ALL is set. In case something like this comes up again: `cmake --graphviz=targets.dot` is quite useful to see why a target is included as part of `ninja all`. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D109611
2021-05-12[cmake] Add support for multiple distributionsShoaib Meenai3-25/+10
LLVM's build system contains support for configuring a distribution, but it can often be useful to be able to configure multiple distributions (e.g. if you want separate distributions for the tools and the libraries). Add this support to the build system, along with documentation and usage examples. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D89177
2021-02-04[clang] Add AddClang.cmake to the list of the CMake modules that are installedAndrzej Warzynski1-0/+1
This makes sure that AddClang.cmake is installed alongside other Clang CMake modules. This mirrors LLVM and MLIR in this respect and is required when building the new Flang driver out of tree (as it depends on Clang and includes AddClang.cmake). Reviewed By: bogner Differential Revision: https://reviews.llvm.org/D94533
2020-06-30Make it possible for client code to consume CLANG_LINK_CLANG_DYLIBserge-sans-paille1-0/+1
If a client code wants to consume clang libraries, it needs to know CLANG_LINK_CLANG_DYLIB value in order to decide whether to use the DYLIB or individual components. Differential Revision: https://reviews.llvm.org/D82291
2020-05-06Reland [libclang] Install both libclang.a and libclang.so when ↵Han Zhu1-31/+41
LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-04-28Revert f8990feb125a "[libclang] Install both libclang.a and libclang.so when ↵Hans Wennborg1-32/+30
LIBCLANG_BUILD_STATIC=ON" This broke builds configured with $ cmake -GNinja -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=clang' '-DLLVM_TARGETS_TO_BUILD=X86' -DLLVM_ENABLE_PIC=OFF ../llvm CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type This reverts commit f8990feb125a0f8d3f2892a589bc6fad3c430858.
2020-04-27[libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ONHan Zhu1-30/+32
When LIBCLANG_BUILD_STATIC=ON and LLVM_ENABLE_PIC=ON, PIC version of libclang.a and libclang.so are built as expected. However libclang.a is not installed. Looking at the macro llvm_add_library(), when both SHARED and STATIC are set, it renames the static library to ${name}_static and then adds it to targets. But when add_clang_library() calls install, it only checks if ${name} is in targets. To work around this issue, loop through both ${name} and ${name}_static and install both of them if they're in targets. This is still correct if only shared or static library is built. In those cases, only ${name} is added to targets and cmake install will generate the right install script depending on the library's type. Test Plan: cmake with LIBCLANG_BUILD_STATIC=ON and then ninja install, from master and this diff. Compare the result directory trees. Confirm that only difference is the added libclang.a. Differential Revision: https://reviews.llvm.org/D78534
2020-04-03[CMAKE] Plumb include_directories() into tablegen()Stephen Neuendorffer1-1/+1
Previously, the tablegen() cmake command, which defines custom commands for running tablegen, included several hardcoded paths. This becomes unwieldy as there are more users for which these paths are insufficient. For most targets, cmake uses include_directories() and the INCLUDE_DIRECTORIES directory property to specify include paths. This change picks up the INCLUDE_DIRECTORIES property and adds it to the include path used when running tablegen. As a side effect, this allows us to remove several hard coded paths to tablegen that are redundant with specified include_directories(). I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which seems generically useful. There are several users in clang which apparently don't have the current directory as an include_directories(). This could be considered separately. The new version of this path uses list APPEND rather than list TRANSFORM, in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then we can use list TRANSFORM instead. Differential Revision: https://reviews.llvm.org/D77156
2020-04-03Revert "[CMAKE] Plumb include_directories() into tablegen()"Stephen Neuendorffer1-1/+1
This reverts commit ae044c5b0caa095602b6ef4cca40d57efc26a8f6. This breaks the buildbots, which use an older version of cmake.
2020-04-03[CMAKE] Plumb include_directories() into tablegen()Stephen Neuendorffer1-1/+1
Previously, the tablegen() cmake command, which defines custom commands for running tablegen, included several hardcoded paths. This becomes unwieldy as there are more users for which these paths are insufficient. For most targets, cmake uses include_directories() and the INCLUDE_DIRECTORIES directory property to specify include paths. This change picks up the INCLUDE_DIRECTORIES property and adds it to the include path used when running tablegen. As a side effect, this allows us to remove several hard coded paths to tablegen that are redundant with specified include_directories(). I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which seems generically useful. There are several users in clang which apparently don't have the current directory as an include_directories(). This could be considered separately. Differential Revision: https://reviews.llvm.org/D77156
2019-12-16Always -I clang/include when tblgen'ing in Clang.John McCall1-1/+2
2019-10-04[CMake] Clang: Don't use object libraries with XcodeJordan Rose1-2/+6
Undoes some of the effects of r360946 when using the Xcode CMake generator---it doesn't handle object libraries correctly at all. Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't actually test it. Should have no effect on non-Xcode generators. https://reviews.llvm.org/D68430 llvm-svn: 373769
2019-07-12cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macrosTom Stellard1-2/+2
Summary: This will simplify the macros by allowing us to remove the hard-coded list of libraries that should be installed when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled. Reviewers: beanz, smeenai Reviewed By: beanz Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64580 llvm-svn: 365902
2019-07-11Rename libclang_shared to libclang-cppSylvestre Ledru1-1/+1
Summary: Fix bug 42475 Reviewers: beanz, tstellar Reviewed By: beanz Subscribers: kimgr, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64278 llvm-svn: 365831
2019-07-03cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard1-0/+9
Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
generated by cgit v1.1 at 2024-08-15 07:14:23 +0000