`find_program(<VAR> ...)` sets <VAR> to <VAR>-NOTFOUND if nothing was found.
So we need to compare <VAR> with "<VAR>-NOTFOUND" or just use `if([NOT] <VAR>)`, because `if(<VAR>)` is false if `<VAR>` ends in the suffix -NOTFOUND.
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D85958
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
These definitions are needed by any file which uses gtest. Previously we
were adding them in the add_unittest function, but over time we've
accumulated libraries (which don't go through add_unittest) building on
gtest and this has resulted in proliferation of the definitions.
Making this a part of the library interface enables them to be managed
centrally. This follows a patch for -Wno-suggest-override (D84554) which
took a similar approach.
Differential Revision: https://reviews.llvm.org/D84748
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This reverts commit b497665d98ad5026b1d3d67d5793a28fefe27bea.
Spent some time trying to reproduce this locally, reverting in a
desparate attempt to fix the sanitizer buildbot:
- http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/28828
I don't know exactly why or how this patch breaks the bots, but it seems
pretty concrete that it's the culprit.
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231a485f1711d576e6131f6755e008abe and follow-ups
64d99cc6abed78c00a2a7863b02ce54911a5264f and
f9fec0447e12da9e8cf4b628f6d45f4941e7d182.
The /Zc:__cplusplus option fixes GTEST_LANG_CXX11 value but not GTEST_HAS_TR1_TUPLE,
so we still need to force the latter off.
Still pass the option since it is required by https://reviews.llvm.org/D78186 too.
Differential Revision: https://reviews.llvm.org/D84023
This drops a GNU gold workaround and reverts the revert commit rL366708.
Before binutils 2.34, gold -O2 and above did not correctly handle R_386_GOTOFF to
SHF_MERGE|SHF_STRINGS sections: https://sourceware.org/bugzilla/show_bug.cgi?id=16794
From the original review:
... it reduced the size of a big ARM-32 debug image by 33%. It contained ~68M
of relocations symbols out of total ~71M symbols (96% of symbols table was
generated for relocations with symbol).
-Wl,-O2 (and -Wl,-O3) is so rare that we should just lower the
optimization level for LLVM_LINKER_IS_GOLD rather than pessimizing all users.
BUG_REPORT_URL is currently used both in LLVM and in Clang but declared
only in the latter. This means that it's missing in standalone clang
builds and the driver ends up outputting:
PLEASE submit a bug report to and include [...]
(note the missing URL)
To fix this, include LLVM_PACKAGE_BUGREPORT in LLVMConfig.cmake
(similarly to how we pass PACKAGE_VERSION) and use it to fill
BUG_REPORT_URL when building clang standalone.
Differential Revision: https://reviews.llvm.org/D84987
The issue with LLVM_ENABLE_LLD is that it just passes -fuse-ld=lld
to compiler/linker options which makes sense only for those platforms
where cmake invokes a compiler driver for linking. On Windows (MSVC) cmake
invokes the linker directly and requires CMAKE_LINKER to be specified
otherwise it defaults CMAKE_LINKER to be link.exe.
This patch allows BOOTSTRAP_LLVM_ENABLE_LLD to set CMAKE_LINKER in two cases:
* if building for host Windows,
* if crosscompiling for target Windows.
It also skips adding '-fuse-ld=lld' to make lld-link not warning
about 'unknown argument'.
This fixes build with `clang/cmake/caches/DistributionExample.cmake`
on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80873
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8d6a171899b31d072a47dac27258fc5.
This reverts commit 81d68ad27b29b1e6bc93807c6e42b14e9a77eade.
This reverts commit a361aa5249856e333a373df90947dabf34cd6aab.
This reverts commit fa42b7cf2949802ff0b8a63a2e111a2a68711067.
This reverts commit 955f87f947fda3072a69b0b00ca83c1f6a0566f6.
This reverts commit 8b16e45f66e24e4c10e2cea1b70d2b85a7ce64d5.
This reverts commit 308a127a38d1111f3940420b98ff45fc1c17715f.
This reverts commit 274b6b0c7a8b584662595762eaeff57d61c6807f.
This reverts commit 1c7037a2a5576d0bb083db10ad947a8308e61f65.
A previous patch added -Wsuggest-override using a simple add_flag_if_supported(). This causes lots of warnings in LLVM when building with older GCC versions (< 9.2) which suggest adding override to functions that are only marked final. The current flags in both GCC >=9.2 and Clang accept plain final as equivalent to override final.
This patch adds logic to detect versions of -Wsuggest-override that warn on void foo() final and disables them to avoid warning spam in builds using older GCC's. This has the added minor benefit of getting rid of the useless C_SUPPORTS_SUGGEST_OVERRIDE_FLAG CMake cache variable which was set by add_flag_if_supported().
Differential Revision: https://reviews.llvm.org/D84292
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This pacth fix out-of-tree build of Flang after the introduction of acc_gen.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D83835
We should also pass down the LLVM_LIT_ARGS in runtime build mode,
so that the runtime tests can be well controlled as well.
We actually passed this down in clang/runtime/CMakeLists.txt
But not for calls from llvm/runtime/CMakeLists.txt.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D83565
The name of the make program does not necessarily match "ninja",
especially if an alternative implementation like samurai is used.
Using CMAKE_GENERATOR is a more robust detection method, and is
already used elsewhere in this file.
Differential revision: https://reviews.llvm.org/D77091
Do not enforce recommonmark dependency if sphinx is called to build
manpages. In order to do this, try to import recommonmark first
and do not configure it if it's not available. Additionally, declare
a custom tags for the selected builder via CMake, and ignore
recommonmark import failure when 'man' target is used.
This will permit us to avoid the problematic recommonmark dependency
for the majority of Gentoo users that do not need to locally build
the complete documentation but want to have tool manpages.
Differential Revision: https://reviews.llvm.org/D83161
Followup to b8000c0ce845, the library path needs to go in
CMAKE_MODULE_LINKER_FLAGS too, for the sake of a few files
like LLVMHello.dll.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D82888
Summary:
add_unittest was checking that the result of get_target_property was not
"NOTFOUND", but despite what the documentation says, get_target_property
returns <the var>-NOTFOUND on failure.
Reviewers: efriedma, thakis, serge-sans-paille, chandlerc
Reviewed By: serge-sans-paille
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81762
This reverts commit 62841415e685fe8857f75edd1fa92b7d1d08b875.
The commit is a misnomer, and it "made its way in" unintentionally,
through a patch that had it as a depdendency. The change itself ended up
to be just a comment update, but the description is completely wrong.
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl, beanz, phosek, smeenai
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
The cmake build of LLVM now uses the appropriate arm64 arch for the
host triple when building llvm-project on an Apple Silicon mac.
Differential Revision: https://reviews.llvm.org/D82428
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
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
The support is via a new option, OBJECT_ONLY, to avoid breaking changes
- since just specifying "OBJECT" would currently imply also STATIC or
SHARED, depending on BUILD_SHARED_LIBS.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
I'm currently working to port `libc++` to Solaris. There exists a slightly
bitrotten port already, which was done on Illumos, an OpenSolaris
derivative. In order not to break that port with my work, I need to test
the result on both Solaris and Illumos. While doing so, it turned out that
Illumos `ld` doesn't support the `-z discard-sections=unused` option
currently used on SunOS unconditionally.
While there exists a patch
<https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/developer/clang-90/patches/02-cmake_modules_AddLLVM.cmake.patch>
for LLVM 9.0 in the OpenIndiana repository, it apparently hasn't been
submitted upstream and is completely wrong: it replaces
`-z discard-sections=unused` with `-z ignore`. In terms of the equivalent
`gld` options, this means replacing `--gc-sections` with `--as-needed`.
This patch instead tests if the linker actually supports the option before
using it.
Tested on `amd64-pc-solaris2.11` (all of Solaris 11.4, 11.3 and OpenIndiana
2020.04).
Differential Revision: https://reviews.llvm.org/D81545
On Apple platforms, linking against libSystem.dylib is sufficient, and
some Apple platforms don't provide libm.dylib. On those platforms, adding
-lm to CMAKE_REQUIRED_LIBRARIES causes all subsequent compile-flag checks
to fail due to the missing library.
Differential Revision: https://reviews.llvm.org/D81265
As LLVM has moved from SVN to git, there is no need to
keep SVN related code. Also, this code piece was never used.
Differential Revision: https://reviews.llvm.org/D79400
cmake configure fails when it tries to setup target for llvm_vcsrevision_h
This happens only when source is checked out using repo in a read
only filesystem, because cmake tries to create `.git/logs/HEAD` file.
This patch:
1. Recovers from failure gracefully.
2. Ensures that VCSRevision.h is successfully created and updated
in above scenarios.
Differential Revision: https://reviews.llvm.org/D79400
After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.
Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.
Differential Revision: https://reviews.llvm.org/D80534
