summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/AddLLVM.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Use PUBLIC link mode for static librariesPetr Hosek2020-03-021-1/+1
| | | | | | | | | | | | Using INTERFACE prevents the use of imported libraries as we've done in 00b3d49 because these aren't linked against the target, they're only made part of the interface. This doesn't affect the output since static libraries aren't being linked into, but it enables the use of imported libraries. Differential Revision: https://reviews.llvm.org/D74106 (cherry picked from commit 50a6d3a6486d81d21a2c31ce8522321e19bed35e)
* [CMake] Default to static linking for subprojects.Michael Kruse2020-02-261-2/+13
| | | | | | | | | | | | | | | | Pass plugins introduced in D61446 do not support dynamic linking on Windows, hence the option LLVM_${name_upper}_LINK_INTO_TOOLS can only work being set to "ON". Currently, it defaults to "OFF" such that such plugins are inoperable by default on Windows. Change the default for subprojects to follow LLVM_ENABLE_PROJECTS. Reviewed By: serge-sans-paille, MaskRay Differential Revision: https://reviews.llvm.org/D72372 (cherry picked from commit 6369b9bf31188bdd472299252deb6db3f650864b) This is for PR45001.
* Add llvm-cov to LLVM_TOOLCHAIN_TOOLSHans Wennborg2020-02-251-0/+1
| | | | | | See https://github.com/llvm/llvm-project/issues/141 (cherry picked from commit dcd89b3de6de891bfcc59189cda1ea059fbdcdb5)
* Fix several issues with compiler extensionsserge-sans-paille2020-01-101-14/+22
| | | | | | | | | | | | | | | | - Update documentation now that the move to monorepo has been made - Do not tie compiler extension testing to LLVM_BUILD_EXAMPLES - No need to specify LLVM libraries for plugins - Add NO_MODULE option to match Polly specific requirements (i.e. building the module *and* linking it statically) - Issue a warning when building the compiler extension with LLVM_BYE_LINK_INTO_TOOLS=ON, as it modifies the behavior of clang, which only makes sense for testing purpose. Still mark llvm/test/Feature/load_extension.ll as XFAIL because of a ManagedStatic dependency that's going to be fixed in a seperate commit. Differential Revision: https://reviews.llvm.org/D72327
* [cmake] Use relative cmake binary dir for processing pass plugins.Michael Kruse2020-01-071-10/+12
| | | | | | | | | | | | | https://reviews.llvm.org/D61446 introduced a new function to process pass plugins that used CMAKE_BINARY_DIR. This is problematic when LLVM is a subproject. Instead use LLVM_BINARY_DIR to get the right relative directory for cmake. Patch by Alan Baker <alanbaker@google.com> Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D72109
* [CMake] Pass symlink dependency to add_llvm_install_targets explicitlyPetr Hosek2020-01-061-5/+12
| | | | | | | | | | | | | | | | | | | | The install-${name}-stripped targets don't strip when ${name} is being symlinked, e.g. llvm-ar or llvm-objcopy. The problem is that llvm_install_symlink passes install-${dest} as a dependency of install-${name}, e.g. install-llvm-ar becomes a dependency of both install-llvm-ranlib and install-llvm-ranlib-stripped. What this means is that when installing a distribution that contains both llvm-ar and llvm-ranlib is that first the stripped version of llvm-ar is installed (by the install-llvm-ar-stripped target) and then it's overwritten by an unstripped version of llvm-ar bnecause install-llvm-ranlib-stripped has install-llvm-ranlib as a dependency as mentioned earlier. To avoid this issue, rather than passing the install-${dest} as dependency, we introduce a new argument to add_llvm_install_targets for symlink target which expands it into an appropriate dependency, i.e. install-${dest} for install-${name} target and install-${dest}-stripped for install-${name}-stripped. Differential Revision: https://reviews.llvm.org/D71951
* [cmake] Remove install from add_llvm_example_library.Florian Hahn2020-01-041-4/+3
| | | | | This should fix http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/30086
* Re-apply "[Examples] Add IRTransformations directory to examples."Florian Hahn2020-01-041-0/+12
| | | | | | This reverts commit 19fd8925a4afe6efd248688cce06aceff50efe0c. Should include a fix for PR44197.
* Generalize the pass registration mechanism used by Polly to any third-party toolserge_sans_paille2020-01-021-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
* Don't call export_symbols.py with duplicate libsDavid Tenty2019-12-111-0/+1
| | | | | | | | | | | | | | | | Summary: export_symbols.py discards duplicate symbols, assuming they have public definitions, so if we end up calling it with duplicate libraries we will end up with an inaccurate export list. Reviewers: jasonliu, stevewan, john.brawn Reviewed By: john.brawn Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70918
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Don't set LLVM_NO_DEAD_STRIP on AIXDavid Tenty2019-11-131-1/+1
| | | | | | | | | | | | | | | | | Summary: when building plugins, as AIX has symbols in it's standard library that must be garbage collected or we will see link errors. Export lists will handle this instead on AIX. Reviewers: stevewan, sfertile, jasonliu, xingxue, DiggerLin Reviewed By: DiggerLin Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70130
* [NFC] Add SUPPORT_PLUGINS to add_llvm_executable()David Tenty2019-11-061-1/+6
| | | | | | | | | | | | | | | | | | | Summary: this allows us to move logic about when it is appropriate set LLVM_NO_DEAD_STRIP out of each tool and into add_llvm_executable, which will enable future platform specific handling. This is a follow on to the reverted D69356 Reviewers: hubert.reinterpretcast, beanz, lhames Reviewed By: beanz Subscribers: mgorny, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69638
* Add more binutils tools to LLVM_INSTALL_TOOLCHAIN_ONLY targetSam Clegg2019-11-041-0/+16
| | | | | | | | Also add the aliases for these tools so that LLVM_INSTALL_BINUTILS_SYMLINKS and LLVM_INSTALL_TOOLCHAIN_ONLY can work together. Differential Revision: https://reviews.llvm.org/D69635
* Revert "[NFC] Rename LLVM_NO_DEAD_STRIP"David Tenty2019-10-301-2/+2
| | | | This reverts commit 11c2a85db8849db1a5907e80d9966592248ef825.
* [NFC] Rename LLVM_NO_DEAD_STRIPDavid Tenty2019-10-251-2/+2
| | | | | | | | | | | | | | | | | Summary: The variable LLVM_NO_DEAD_STRIP is set in LLVM cmake files when building executables that might make use of plugins .The name of the variable does not convey the actual intended usage (i.e. for use with tools that have plugins), just what the eventual effect of setting in on some (i.e. not garbage collecting unused symbols). This patch renames it to LLVM_SUPPORT_PLUGINS to convey the intended usage, which will allow subsequent patches to add behavior to support that in different ways without confusion about whether it will do on, for example, non-gnu platforms. Reviewers: hubert.reinterpretcast, stevewan Reviewed By: stevewan Subscribers: cfe-commits, mgorny, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D69356
* [CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compilerDavid Zarzycki2019-09-101-1/+8
| | | | | | | | GCC (unlike clang!) warns about C++ flags when compiling C. https://reviews.llvm.org/D67171 llvm-svn: 371521
* [CMake] LLVM_COMPILE_FLAGS also applies to C filesDavid Zarzycki2019-09-061-1/+1
| | | | | | | | | LLVM_COMPILE_FLAGS also applies to C files, otherwise tuning flags, etc. won't be picked up. https://reviews.llvm.org/D67171 llvm-svn: 371173
* Fix rpath for MacOS/iOSHaibo Huang2019-08-091-1/+1
| | | | | | | | | | | | Summary: libs can be installed to ../lib64. Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65972 llvm-svn: 368398
* Add order-dependencies to object librariesChris Bieneman2019-08-061-0/+3
| | | | | | | | | | | | | | | | Summary: If you are generating an object library that depends on table-gen generate sources, you need the object library to depend on the tablgen target. Currently llvm_add_library doesn't add dependencies for object libraries at all, which is clearly problematic. Reviewers: compnerd, hintonda, smeenai Reviewed By: smeenai Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65818 llvm-svn: 368074
* [CMake] Add mapping for IBM XL -qnoeh and -qnorttiHubert Tong2019-08-061-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch maps in the `-qnoeh` and `-qnortti` options for building with IBM XL compilers. Reviewers: daltenty, xingxue, jasonliu Reviewed By: daltenty Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65669 llvm-svn: 368050
* [cmake] Fix typo where a varible was checked for Apple instead of DarwinNathan Lanza2019-07-191-1/+1
| | | | | | | | | | Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64965 llvm-svn: 366515
* [cmake] Only run llvm-codesign if targetting apple on an apple hostNathan Lanza2019-07-181-1/+1
| | | | | | | | | | | | | | | | | Summary: Other platforms don't have the capability to perform llvm_codesign step. If LLVM_CODESIGNING_IDENTITY is set then this chunk of code would attempt to codesign if the target was Apple. But when cross compiling to Darwin from Linux, for example, this step would fail. So test if the host is Apple as well. Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64942 llvm-svn: 366498
* cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macrosTom Stellard2019-07-121-6/+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
* Fix issues building libraries as more than one type with XcodeChris Bieneman2019-07-081-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: CMake+Xcode doesn't seem to handle targets that only have object sources. This patch works around that limitation by adding a dummy soruce file to any library target that is generated by llvm_add_library when object libraries are generated. Object libraries are generated whenever llvm_add_library is passed more than one library type, which is now the default case for clang static libraries (which generate STATIC and OBJECT libraries). Reviewers: zturner, compnerd, joanlluch Reviewed By: joanlluch Subscribers: joanlluch, xbolva00, mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64300 llvm-svn: 365365
* Add llvm-symbolizer to LLVM_TOOLCHAIN_TOOLS (PR40152)Hans Wennborg2019-06-251-0/+1
| | | | | | So that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds. llvm-svn: 364277
* [LLVM-C] Add LLVM-C.dll to Windows installer packageHans Wennborg2019-06-251-1/+3
| | | | | | | | | | | | This is a follow up to D56781, D56774 and D35077 to makes the LLVM-C.dll file and LLVM-C.lib be installed on Windows, just like LTO.dll and LTO.lib are. Patch by Jakob Bornecrantz! Differential revision: https://reviews.llvm.org/D63717 llvm-svn: 364275
* tools: add `llvm-nm` and `llvm-objcopy` to toolsSaleem Abdulrasool2019-06-031-0/+2
| | | | | | | | | Add `nm` and `objcopy` to the default value for the tools that we install now that they are sufficiently feature complete to replace bintuils' implementation. Patch by Jiang Yi! llvm-svn: 362425
* [CMake] Feed BUNDLE_PATH through llvm target wrappersChris Bieneman2019-05-311-4/+4
| | | | | | This feeds the new llvm_codsign BUNDLE_PATH option through from the llvm target wrapper functions, so that you can specify the BUNDLE_PATH on the target's codesign. llvm-svn: 362248
* Support codesigning bundles and forcingChris Bieneman2019-05-301-3/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources. This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles. The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties. The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary. Reviewers: jkorous, bogner Reviewed By: bogner Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62693 llvm-svn: 362169
* [cmake] Add custom command to touch archives on Darwin so ninja won't ↵Don Hinton2019-05-211-0/+12
| | | | | | | | | | | | | | | | | | | | rebuild them. Summary: clang and newer versions of ninja use high-resolutions timestamps, but older versions of libtool on Darwin don't, so the archive will often get an older timestamp than the last object that was added or updated. To fix this, we add a custom command to touch the archive after it's been built so that ninja won't rebuild it unnecessarily the next time it's run. Reviewed By: beanz Tags: #llvm Differential Revision: https://reviews.llvm.org/D62172 llvm-svn: 361280
* [CMake] Specify component for all target typesPetr Hosek2019-05-211-4/+3
| | | | | | | | | | This addresses an issue introduced in r360230 which broke existing use cases of LLVM_DISTRIBUTION_COMPONENTS since ARCHIVE and LIBRARY target types are no longer handled as components. Differential Revision: https://reviews.llvm.org/D62176 llvm-svn: 361223
* [CMake] Install import librariesMartin Storsjo2019-05-081-16/+3
| | | | | | | | | | | | Simplify the cmake logic to install both runtime and import libraries (treated as ARCHIVE), as the later are needed to link against llvm. Patch by Julien Schueller! Differential Revision: https://reviews.llvm.org/D61425 llvm-svn: 360230
* build: add option to disable unwind tablesSaleem Abdulrasool2019-05-021-0/+4
| | | | | | | | | The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to the final binaries. These should not be needed normally, particularly when exceptions are disabled. This enables shrinking `lldb-server` by ~18% (3 MiB) when built with gold. llvm-svn: 359819
* Add llvm-profdata to LLVM_TOOLCHAIN_TOOLSRussell Gallop2019-04-301-0/+1
| | | | | | | | | | This is required for using PGO on Windows but isn't in the Windows release packages. Windows packages are built with LLVM_INSTALL_TOOLCHAIN_ONLY so only includes llvm "tools" listed here. Differential Revision: https://reviews.llvm.org/D61317 llvm-svn: 359569
* [CMake] Use add_dependencies in add_llvm_install_targetsAlex Langford2019-04-231-2/+16
| | | | | | | | | | | Summary: The CMake documentation says that the `DEPENDS` field of add_custom_target is for files and output of custom commands. Adding a dependency on a target should be done with `add_dependency`. Differential Revision: https://reviews.llvm.org/D60879 llvm-svn: 359042
* [CMake] Allow custom extensions for externalized debug infoStefan Granitz2019-04-181-5/+12
| | | | | | | | | | | | | | | | Summary: Extra flexibility for emitting debug info to external files (remains Darwin only for now). LLDB needs this functionality to emit a LLDB.framework.dSYM instead of LLDB.dSYM when building the framework, because the latter could conflict with the driver's lldb.dSYM when emitted in the same directory on case-insensitive file systems. Reviewers: friss, bogner, beanz Subscribers: mgorny, aprantl, llvm-commits, #lldb Tags: #llvm Differential Revision: https://reviews.llvm.org/D60862 llvm-svn: 358685
* [cmake] Reset variable before using itShoaib Meenai2019-03-261-0/+3
| | | | | | | | | | | | | | | | 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] Correct CMake message modeAlex Langford2019-03-151-1/+1
| | | | | | | | | | | | | | | | Summary: This wasn't actually printing out a CMake warning, it was prepending "WARN" to the message. Reviewers: zturner Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59432 llvm-svn: 356297
* [AIX][CMake] Changes for building on AIX with XL and GCCJason Liu2019-03-131-1/+7
| | | | | | | | | | | | | | | | | | | Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
* [OptRemarks] Make OptRemarks more generic: rename OptRemarks to RemarksFrancis Visoiu Mistrih2019-03-051-1/+1
| | | | | | | | | | | | | | | Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439
* [cmake] Create exports for umbrella library targetsShoaib Meenai2019-03-051-0/+2
| | | | | | | | | | 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
* CMake: Fix stand-alone clang builds since r353268Tom Stellard2019-02-201-0/+3
| | | | | | | | | | | | | | | | | | | Summary: Handle the case where LLVM_MAIN_SRC_DIR is not set and also use LLVM_CMAKE_DIR for locating installed cmake files rather than LLVM_CMAKE_PATH. Reviewers: phosek, andrewrk, smeenai Reviewed By: phosek, andrewrk, smeenai Subscribers: mgorny, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D58204 llvm-svn: 354417
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-02-061-30/+30
| | | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang and lldb. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM, Clang and lldb, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 353268
* [CMake] Add install targets for utilities to LLVM exports if ↵Stefan Granitz2019-02-011-11/+21
| | | | | | | | | | | | | | | | LLVM_INSTALL_UTILS=ON Summary: D56606 was only appending target names to the `LLVM_EXPORTS`/`LLVM_EXPORTS_BUILDTREE_ONLY` properties. Targets showed up correctly in the build-tree `LLVMExports.cmake`, but they were missing in the installed one (as we found in https://bugs.llvm.org/show_bug.cgi?id=40443), because install did not register them explicitly. Reviewers: mgorny, smeenai, beanz, gottesmm, dschuff, tstellar, serge-sans-paille Reviewed By: smeenai Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57383 llvm-svn: 352869
* Revert "[CMake] Unify scripts for generating VCS headers"Petr Hosek2019-01-311-30/+30
| | | | | | This reverts commits r352729 and r352731: this broke Sanitizer Windows bots llvm-svn: 352733
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-01-311-30/+30
| | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM and Clang, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 352729
* [CMake] Accept ENTITLEMENTS in llvm_add_library()Stefan Granitz2019-01-301-2/+2
| | | | | | | | | | | | | | Summary: We added support for code signing entitlements in add_llvm_executable() with D54443. In the future it would be useful to have this functionality available also for libraries. Reviewers: beanz, bogner Reviewed By: bogner Subscribers: mgorny, llvm-commits, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D57334 llvm-svn: 352628
* [cmake] Fix get_llvm_lit_path() to respect LLVM_EXTERNAL_LIT alwaysMichal Gorny2019-01-281-1/+0
| | | | | | | | | | | | | | | | | | | | | Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT, and require the fallback to be defined explicitly as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone after r346888. The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache variable and an optional pre-definition of default value from caller (e.g. libcxx). It included a hack to make this work by assigning the value back and forth but it was fragile and stopped working in libcxx. The new logic is simpler and more transparent. Default value is provided in a separate variable, and used only when user-specified variable is empty (i.e. not overriden). Differential Revision: https://reviews.llvm.org/D57282 llvm-svn: 352374
* [CMake] Export utility targets to the build/install tree depending on ↵Stefan Granitz2019-01-111-0/+3
| | | | | | | | | | | | | | | | | | LLVM_BUILD/INSTALL_UTILS Summary: Allow external projects to import test-related targets like FileCheck, count, not etc. and query binary paths, properties, etc. This would be useful for LLDB, because it reduces the difference between in-tree vs. standalone builds and simplifies CMake logic. Reviewers: chapuni, gottesmm, beanz Reviewed By: beanz Subscribers: mgorny, lldb-commits, llvm-commits, #lldb Differential Revision: https://reviews.llvm.org/D56606 llvm-svn: 350959
OpenPOWER on IntegriCloud