summaryrefslogtreecommitdiffstats
path: root/clang/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
* Always -I clang/include when tblgen'ing in Clang.John McCall2019-12-161-1/+2
|
* [CMake] Clang: Don't use object libraries with XcodeJordan Rose2019-10-041-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
* cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macrosTom Stellard2019-07-121-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
* Rename libclang_shared to libclang-cppSylvestre Ledru2019-07-111-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
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-031-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
* [cmake] Remove old unused version of FindZ3.cmake from clang [NFC]Don Hinton2019-05-241-0/+0
| | | | | | | | | | | | | Summary: This file was moved to llvm in D54978, r356929, but the old file was never removed. Reviewed By: beanz Tags: #clang Differential Revision: https://reviews.llvm.org/D62343 llvm-svn: 361663
* Fix BUILD_SHARED_LIBS for clang which broke in D61909Chris Bieneman2019-05-211-1/+7
| | | | | | llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build. llvm-svn: 361271
* Re-land: Add Clang shared library with C++ exportsChris Bieneman2019-05-171-2/+5
| | | | | | | | | Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. llvm-svn: 360985
* Revert r360946 "Add Clang shared library with C++ exports"Nico Weber2019-05-171-5/+2
| | | | | | | | It breaks LLVM_ENABLE_PIC=OFF builds, and it's not clear if the object library approach doesn't impact the normal clang binary. llvm-svn: 360973
* Add Clang shared library with C++ exportsChris Bieneman2019-05-161-2/+5
| | | | | | | | | | | | | | | | | Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. Reviewers: tstellar, winksaville Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61909 llvm-svn: 360946
* [clang-fuzzer] Include ExternalProject before using it.Matt Morehouse2019-04-051-0/+1
| | | | | | | Some versions of CMake require ExternalProject to be included before we can use ExternalProject_Add. llvm-svn: 357803
* [cmake] Reset variable before using itShoaib Meenai2019-03-261-1/+2
| | | | | | | | | | | | | | | | A bunch of macros use the same variable name, and since CMake macros don't get their own scope, the value persists across macro invocations, and we can end up exporting targets which shouldn't be exported. Clear the variable before each use to avoid this. Converting these macros to functions would also help, since it would avoid the variable leaking into its parent scope, and that's something I plan to follow up with. It won't fully address the problem, however, since functions still inherit variables from their parent scopes, so if someone in the parent scope just happened to use the same variable name we'd still have the same issue. llvm-svn: 357036
* Moved everything SMT-related to LLVM and updated the cmake scripts.Mikhail R. Gadelha2019-03-251-51/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
* [cmake] Create exports for umbrella library targetsShoaib Meenai2019-03-051-0/+1
| | | | | | | | | | When using the umbrella llvm-libraries and clang-libraries targets, we should export all library targets, otherwise they'll be part of our distribution but not usable from the CMake package. Differential Revision: https://reviews.llvm.org/D58862 llvm-svn: 355354
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
* [clang] Add CMake target for installing clang's CMake exportsShoaib Meenai2019-02-201-2/+11
| | | | | | | | This mirrors LLVM's install-cmake-exports target. Differential Revision: https://reviews.llvm.org/D58480 llvm-svn: 354527
* [clang] Switch to LLVM_ENABLE_IDEShoaib Meenai2019-02-201-2/+2
| | | | | | | | | | | | r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more directly and can be overridden by a user. Make the corresponding change in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should be available for both standalone and integrated builds. Differential Revision: https://reviews.llvm.org/D58284 llvm-svn: 354525
* [clang] Add build and install targets for clang librariesShoaib Meenai2019-02-151-0/+2
| | | | | | | | | | | | | | | This is modeled after the existing llvm-libraries target. It's a convenient way to include all clang libraries in a distribution. This differs slightly from the llvm-libraries target in that it adds any library added via add_clang_library, whereas llvm-libraries only includes targets added via add_llvm_library that didn't use the MODULE or BUILDTREE_ONLY arguments. add_clang_library doesn't appear to have any equivalents of those arguments, so the conditions don't apply. Differential Revision: https://reviews.llvm.org/D58269 llvm-svn: 354141
* [clang] Create install targets for non-shared librariesShoaib Meenai2019-02-151-1/+1
| | | | | | | | | | | I don't see a reason for these to not have install targets created, which in turn allows them to be bundled in distributions. This doesn't affect the "install" target, since that just runs all CMake install rules (and we were already creating install rules for these). Differential Revision: https://reviews.llvm.org/D58268 llvm-svn: 354140
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-091-0/+51
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-071-51/+0
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* [analyzer] Improved cmake configuration for Z3Enrico Steffinlongo2018-10-131-2/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html). Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON. Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7 Reviewers: NoQ, george.karpenkov, mikhail.ramalho Reviewed By: george.karpenkov Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus Tags: #clang Differential Revision: https://reviews.llvm.org/D50818 llvm-svn: 344464
* Build clang-headers when building clang tools.Haojian Wu2018-10-011-0/+1
| | | | | | | | | | | | | | | | | Summary: clang tools require clang headers to work on real project, e.g. when we build clangd via `ninja clangd`, we expect the binary can run on real-world project (without running another command `ninja clang-headers`). Reviewers: sammccall Reviewed By: sammccall Subscribers: mgorny, ilya-biryukov, ioeric, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52714 llvm-svn: 343459
* Revert r323051 "[cmake] Use CLANG_BINARY_DIR to determine the build directory."Vassil Vassilev2018-01-241-1/+1
| | | | | | | | This broke swift builds. Thanks for the post-commit review of Chris Bieneman and Davide Italiano! llvm-svn: 323368
* [cmake] Use CLANG_BINARY_DIR to determine the build directory.Vassil Vassilev2018-01-201-1/+1
| | | | | | | The patch puts the ClangConfig.cmake in the expected location when clang is embedded into a framework. llvm-svn: 323051
* [clang] Use add_llvm_install_targetsShoaib Meenai2017-11-301-10/+6
| | | | | | | | | | Use this function to create the install targets rather than doing so manually, which gains us the `-stripped` install targets to perform stripped installations. Differential Revision: https://reviews.llvm.org/D40675 llvm-svn: 319489
* [clang-fuzzer] Fix incremental builds of the fuzzerVitaly Buka2017-10-311-11/+6
| | | | | | | | | | | | | | | Summary: Don't use BUILD_IN_SOURCE keep git checkout clean Don't forward CMAKE_GENERATOR as ExternalProject_Add should do it already Reset UPDATE_COMMAND to avoid git checkout updates on each build Reviewers: kcc, morehouse Subscribers: cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D39445 llvm-svn: 317035
* [clang-proto-fuzzer] Use ToT protobuf-mutator.Matt Morehouse2017-10-181-1/+1
| | | | llvm-svn: 316103
* [clang-fuzzer] Build with newer protobuf-mutator.Matt Morehouse2017-10-111-1/+1
| | | | llvm-svn: 315506
* Update libprotobuf-mutator revisionVitaly Buka2017-08-221-1/+1
| | | | llvm-svn: 311428
* Integrate Kostya's clang-proto-fuzzer with LLVM.Matt Morehouse2017-08-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The clang-proto-fuzzer models a subset of C++ as a protobuf and uses libprotobuf-mutator to generate interesting mutations of C++ programs. Clang-proto-fuzzer has already found several bugs in Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747, https://bugs.llvm.org/show_bug.cgi?id=33749). As with clang-fuzzer, clang-proto-fuzzer requires the following cmake flags: - CMAKE_C_COMPILER=clang - CMAKE_CXX_COMPILER=clang++ - LLVM_USE_SANITIZE_COVERAGE=YES // needed for libFuzzer - LLVM_USE_SANITIZER=Address // needed for libFuzzer In addition, clang-proto-fuzzer requires: - CLANG_ENABLE_PROTO_FUZZER=ON clang-proto-fuzzer also requires the following dependencies: - binutils // needed for libprotobuf-mutator - liblzma-dev // needed for libprotobuf-mutator - libz-dev // needed for libprotobuf-mutator - docbook2x // needed for libprotobuf-mutator - Recent version of protobuf [3.3.0 is known to work] A working version of libprotobuf-mutator will automatically be downloaded and built as an external project. Implementation of clang-proto-fuzzer provided by Kostya Serebryany. https://bugs.llvm.org/show_bug.cgi?id=33829 Reviewers: kcc, vitalybuka, bogner Reviewed By: kcc, vitalybuka Subscribers: thakis, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D36324 llvm-svn: 310408
* [CMake] NFC. Add clang-tablegen-targets utility targetChris Bieneman2017-07-281-0/+7
| | | | | | | | By creating this target other projects that depend on clang-generated headers (like LLDB) will no longer be order-dependent on Clang being processed by CMake first. Also, by creating a dummy of this target in ClangConfig.cmake, projects that can build against out-of-tree clang can freely depend on the target without needing to have conditionals for if clang is in-tree or out-of-tree. llvm-svn: 309390
* [cmake] Support Gentoo install for z3Michal Gorny2017-04-081-1/+1
| | | | | | | | | | Add the 'z3' subdirectory to the list of possible path suffixes for libz3 header search. The z3 headers are installed in /usr/include/z3 on Gentoo. Differential Revision: https://reviews.llvm.org/D31756 llvm-svn: 299813
* [analyzer] Add new Z3 constraint manager backendDominic Chen2017-04-041-0/+28
| | | | | | | | | | | | Summary: Implement new Z3 constraint manager backend. Reviewers: zaks.anna, dcoughlin, NoQ, xazax.hun Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D28952 llvm-svn: 299463
* [CMake] fix CLANG_INCLUDE_DIRS CMake exportGuillaume Papin2017-03-211-1/+1
| | | | | | | | | | | | | | | | Summary: This change should fixes the export of CLANG_INCLUDE_DIRS variable in ClangConfig.cmake. Unlike for the other variables, CLANG_INSTALL_PREFIX wasn't escaped meaning CLANG_INCLUDE_DIRS resulting in the path "/include" instead of "${CLANG_INSTALL_PREFIX}/include". Reviewers: beanz Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D30911 llvm-svn: 298424
* [CMake] Add CLANG_INCLUDE_DIRS to CMake exportsChris Bieneman2017-02-062-0/+8
| | | | | | This patch adds setting CLANG_INCLUDE_DIRS in the generated CMake package configuration files. llvm-svn: 294207
* [cmake] Hint find_package() to prefer LLVM installed alongside clangMichal Gorny2017-01-312-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Include a path hint for find_package() in ClangConfig.cmake to ensure that CMake prefers LLVM installed alongside clang over the default search path. If two versions of LLVM are installed in the system, and one of them is in PATH, CMake's find_package() magic prefers the CMake directory alongside that install by default. Adding a relative hint makes it possible to prioritize to the install from which find_package() is called. If you want to build e.g. LLDB against another install of LLVM, you can pass LLVM_CONFIG override. In this case, LLDB queries the prefix from llvm-config and uses the CMake files located there. However, when including ClangConfig, the implicit find_package() nevertheless prefers PATH-found LLVM over the one used previously by LLDB, and two versions of LLVMConfig end up being loaded. This could be fixed on LLDB end up by explicitly forcing custom package search location. However, it seems simpler and safer to add a hint to ClangConfig than to track every usage of ClangConfig. Differential Revision: https://reviews.llvm.org/D29304 llvm-svn: 293632
* cmake: Don't try to install exports if there aren't anyJustin Bogner2016-11-082-1/+6
| | | | | | | | | When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's export list to be empty. If this happens the install(EXPORTS) command will fail, but since there isn't anything to install anyway we really just want to skip it. llvm-svn: 286210
* cmake: Support exports correctly with LLVM_DISTRIBUTION_COMPONENTSJustin Bogner2016-11-071-1/+13
| | | | | | | | | | | We need to apply the same export logic in clang as in llvm for LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid when we use this config. This makes using distribution components without setting LLVM_TOOLCHAIN_ONLY=On work correctly. llvm-svn: 286181
* [cmake] Follow LLVM's lead in creating exported tool targets for clang tools.Michael Gottesman2016-10-191-0/+1
| | | | | | | | | | | | This is needed by downstream projects such as swift to get proper cmake dependency information for LLVM/Clang targets. A few months ago I added support for exporting this information for Clang libraries. In order to be incremental, I did not add support for exporting clang tools as well at that time. Now such support is needed, so I am committing this incremental code. llvm-svn: 284658
* Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLSMichael Gottesman2016-07-101-10/+17
| | | | | | | | | | | | | | LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
* Move add_clang_* entry points from the main clang CMakeLists.txt to ↵Michael Gottesman2016-07-091-0/+142
| | | | | | | | | cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
* [cmake] Remove stale comment. NFC.Michael Gottesman2016-06-301-4/+0
| | | | llvm-svn: 274212
* [ClangConfig] Store all of the targets exported in the variable ↵Michael Gottesman2016-06-292-1/+2
| | | | | | CLANG_EXPORTED_TARGETS. llvm-svn: 274180
* [ClangConfig] Unset some variables after we are done using them to configure ↵Michael Gottesman2016-06-291-0/+5
| | | | | | | | | | ClangConfig.cmake.in files. This ensures that the values do not bleed over in between computations. It may make sense in the future to just refactor this code into functions to provide "true scoping". llvm-svn: 274179
* [ClangConfig] Instead of hard coding the ClangTargets location to ↵Michael Gottesman2016-06-292-1/+19
| | | | | | | | /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@. This just makes ClangConfig more consistent with LLVMConfig. llvm-svn: 274178
* [ClangConfig] Follow LLVM's example and only install ↵Michael Gottesman2016-06-291-4/+6
| | | | | | Clang{Config,Target}.cmake when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled. llvm-svn: 274177
* [cmake] Instead of just copying ClangConfig.cmake, configure it using ↵Michael Gottesman2016-06-292-10/+14
| | | | | | | | | ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
* [ClangConfig] Copy ClangConfig.cmake to ↵Michael Gottesman2016-06-291-1/+1
| | | | | | | | | | | | | | ${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}. This is an obvious bug since ClangConfig.cmake looks for ClangTargets.cmake in ${CMAKE_CURRENT_LIST_DIR}. But ClangTargets.cmake is in ${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}, so it will always fail with an in tree build. In the case where clang is built out of tree, this is still correct since CMAKE_BINARY_DIR and CLANG_BINARY_DIR will be the same. llvm-svn: 274168
* [ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR ↵Michael Gottesman2016-06-291-2/+2
| | | | | | with a deref of the variable. llvm-svn: 274158
OpenPOWER on IntegriCloud