summaryrefslogtreecommitdiffstats
path: root/clang/cmake/modules/AddClang.cmake
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
* 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
* [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
* [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] 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
* 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
* [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
* cmake: Don't try to install exports if there aren't anyJustin Bogner2016-11-081-0/+2
| | | | | | | | | 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
OpenPOWER on IntegriCloud