When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.
The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.
LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.
In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.
The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.
Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.
This fixes
https://github.com/llvm/llvm-project/issues/60784.
Differential Revision: https://reviews.llvm.org/D146666
When the runtime dir path includes whitespace (ex. when it's installed
under "Program Files" on Windows), the lack of quotes causes the linker
to interpret the path as one or more arguments. None of these path
fragments exist, so the link fails.
Differential Revision: https://reviews.llvm.org/D145827
The change to potentially use symlinks on Windows was added in
https://reviews.llvm.org/D99170.
LLVM_USE_SYMLINKS was added more recently in
https://reviews.llvm.org/D135578 and allows specifying at configure time
whether or not symlinks should be created. The benefit of using this
option is it allows building the package on a symlink-capable Windows
machine with symlinks disabled so that the resulting package can be used
on a Windows machine that doesn't support symlinks.
Differential Revision: https://reviews.llvm.org/D145443
In D61448 the cmake option `LLVM_ENABLE_UNWIND_TABLES` was added.
Despite the name suggesting that the option enables unwind tables, that
patch only uses it to disable them. That makes a difference for
architectures where unwind tables aren't enabled by default. The lack of
unwind tables impacts backtraces and the current handling of the option
doesn't allow enabling them. This patch makes an ON value of
`LLVM_ENABLE_UNWIND_TABLES` actually enable unwind tables.
Differential Revision: https://reviews.llvm.org/D144178
These have the same purposes but two different implementations.
llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects
flags used both for compilation and linking which is problematic because
some flags may be link-only and trigger unused argument warning when set
during compilation. llvm_check_linker_flag does not have this issue so
we chose it as the prevailaing implementation.
Differential Revision: https://reviews.llvm.org/D143052
The last non-partial-specified target can collect and check source files.
Case A:
llvm_add_library(foo PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(bar PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(baz ...)
baz checks source files in foo, bar, and baz.
Case B:
llvm_add_library(hoge PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(fuga PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(piyo PARTIAL_SOURCES_INTENDED ...)
llvm_check_source_file_list() # Explicitly checks sources in hoge, fuga, and piyo.
Differential Revision: https://reviews.llvm.org/D142256
Follow-up to https://reviews.llvm.org/D142279 for also enabling `libc++` assertions.
This is particularly useful to recover the assertion checks we had with `llvm::Optional`, before moving to `std::optional`.
Differential Revision: https://reviews.llvm.org/D143612
This reverts commit 16e1a49441c51817697138437d8db2c15bc19cb4, essentially reapplying 12d8e7c6ade55bba241259312e3e4bdcf6aeab81. The build bot where this caused issues is supposed to be updated now: https://reviews.llvm.org/D135128#4108588
On my machine this showed no new failures in check-llvm and increased
the testing time from 138 to 142 seconds, for a Release build with
assertions enabled.
Differential Revision: https://reviews.llvm.org/D142279
This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.
Differential Revision: https://reviews.llvm.org/D141738
The LLVM runtime build is used to bootstrap projects with the built LLVM
toolchain. This effectively re-runs CMake with the current build
directory. One problem is that this passes every common CMake variable
to the projects individually, some of which are not necessarily used.
This patch suppresses the unused variable warnings for the runtimes.
The standard CMake invocation should still be able to print out the
unused variables so it should not impact code quality.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D143199
cmake_push_check_state and cmake_pop_check_state doesn't save and
restore CMAKE_EXE_LINKER_FLAGS so we need to do it manually.
Differential Revision: https://reviews.llvm.org/D143088
This change force us to use the top-level CMake's detected tools. We
need to do this as a temporary workaround as when using CMake
versions >= 3.22 we'll pickup the built llvm-ranlib by default if it's
in the path (which it is when doing a sub build via
llvm_ExternalProject_Add for the runtimes).
llvm-ranlib runs into problems on AIX due to missing 64-bit
functionality to be added by
https://reviews.llvm.org/D142479 and https://reviews.llvm.org/D142660.
Once those patches land, this can be reverted.
Differential Revision: https://reviews.llvm.org/D142727
https://reviews.llvm.org/D142405 made this function relying on the
LLVM_NATIVE_ARCH be defined, which is not necessarily the case for
third-party projects that include LLVM as their part.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D142610
There is a typo in the cmake configuration. It should be
RISCVTargetParserTableGen, not RISCVTargetParserTablegen.
This reverts commit 5d02e38f56dfa6c46dd71658c185582af1ffb07b.
If we don't use the index otherwise, if(IN_LIST) is more readable and
doesn't clutter the local scope with index variables.
This was pointed out by @beanz in D96670.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D142405
This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.
Differential Revision: https://reviews.llvm.org/D141738
The header file `llvm/include/llvm/Targetparser/RISCVTargetParser.h`
relies on the auto-generated *.inc file associated to the tablegen
target `RISCVTargetParserTableGen`.
Both clangBasic and clangDriver include `RISCVTargetParser.h`,
therefore we need to make sure that the *.inc file is avaiable to
avoid compilation errors like the following:
FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Targets/RISCV.cpp.o
/usr/bin/c++ [bunch of non interesting stuff] -c <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
In file included from <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp:19:
<path-to>/llvm-project/llvm/include/llvm/TargetParser/RISCVTargetParser.h:29:10: fatal error: llvm/TargetParser/RISCVTargetParserDef.inc: No such file or directory
29 | #include "llvm/TargetParser/RISCVTargetParserDef.inc"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The stand-alone build of `clang` has been tested with the following
script (see [*] for further information):
```
build_llvm=`pwd`/build-llvm
build_clang=`pwd`/build-clang
installprefix=`pwd`/install
llvm=`pwd`/llvm-project
mkdir -p $build_llvm
mkdir -p $installprefix
cmake -G Ninja -S $llvm/llvm -B $build_llvm \
-DLLVM_INSTALL_UTILS=ON \
-DCMAKE_INSTALL_PREFIX=$installprefix \
-DCMAKE_BUILD_TYPE=Release
ninja -C $build_llvm install
cmake -G Ninja -S $llvm/clang -B $build_clang \
-DLLVM_EXTERNAL_LIT=$build_llvm/utils/lit \
-DLLVM_ROOT=$installprefix
```
[*] https://llvm.org/docs/GettingStarted.html#stand-alone-builds
Differential Revision: https://reviews.llvm.org/D141581
In an installation using the all-contained libLLVM.so, individual
components are not available as targets, so we have to look them up in
LLVM_AVAILABLE_LIBS just like llvm_map_components_to_libnames does it.
Here I don't think we need the capitalized names though because we know
the right capitalization. But I might be wrong.
This is required by dragonffi, who call llvm_map_components_to_libnames
on a list containing ${LLVM_NATIVE_ARCH}. Downstream bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1180748.
Differential Revision: https://reviews.llvm.org/D96670
This avoids having to specify the location of all individual tools.
In current builds, one may want to specify LLVM_TABLEGEN, CLANG_TABLEGEN,
LLDB_TABLEGEN, LLVM_CONFIG_PATH, CLANG_PSEUDO_GEN and
CLANG_TIDY_CONFUSABLE_CHARS_GEN; specifying just the base directory
containing all of them is much more convenient.
Factorize the code for setting up use of a tool that is used during
the build (which either is newly built in the same build, or
built in a separate nested cmake build - when cross compiling or
when e.g. optimized tablegen is requested - or used from an existing
prebuilt binary).
Differential Revision: https://reviews.llvm.org/D131052
The dependency was due to the log format. This change switches to the
previously-introduced (D139370) "dependency-free" logger instead of the
protobuf-based one.
A subsequent change will clean out the unnecessary abstraction left
behind.
This change drops the logger unittest, we have sufficient test coverage
via lit tests, and a unit test would require adding, unnecesarily, a log
reader (the reader is expected to be python, for the ML side, and there
is a reader for that under Analysis/models, used for tests).
Differential Revision: https://reviews.llvm.org/D141720
It is possible to build LLVM with just the "llvm" and "cmake" components
checked out. This requires disabling the `LLVM_INCLUDE_BENCHMARKS` and
`LLVM_INCLUDE_TESTS` options. These options are not passed through to
the native build when cross-compiling though, so the build will break if
the "third-party" component is missing. We don't need the benchmarks or
tests for the native build, so disable these unconditionally. This fixes
cross-compiling on Gentoo, where only the required components are
checked out.
Differential Revision: https://reviews.llvm.org/D141196
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
When adding llvm to a build with add_subdirectory, CMAKE_SOURCE_DIR
refers to the source directory of the parent project. We want to use
PROJECT_SOURCE_DIR instead.
Differential Revision: https://reviews.llvm.org/D141521
clang-tblgen is required to cross-compile clang itself. Unlike before,
most of the infrastructure is in place to do this now, and the only
thing preventing it is LLVM_BUILD_UTILS, which doesn't apply to Clang.
I thought about changing this to ${project}_BUILD_UTILS and adding
a CLANG_BUILD_UTILS option, but there seems little point for just one tool.
Instead, it checks whether clang-tblgen was explicitly requested in
LLVM_DISTRIBUTION_COMPONENTS, which is good enough for Gentoo and
other distributions.
Closes https://github.com/llvm/llvm-project/issues/20282.
Differential Revision: https://reviews.llvm.org/D141092
Currently, setting -DLLVM_ENABLE_LLD=ON on windows also requires setting
-DCMAKE_LINKER=lld-link.exe. This is both misleading and redundant.
Fix this by trying to find llvm-link.exe when -DLLVM_ENABLE_LLD=ON is
set and CMAKE_LINKER is not, and aborting otherwise.
Differential Revision: https://reviews.llvm.org/D140534
We were copying it into the installed version of the directory,
but not into the one in the build directory. Because of that it
was not directly usable as a cmake module by subprojects that
also use the driver functionality.
Using CMAKE_CFG_INTDIR in paths that are used in configure_file,
resulted in a folder that is literally called '${CONFIGURATION}'
for the multi-config ninja build.
I think this is a regression from a while ago. Fix this by replacing
CMAKE_CFG_INTDIR with '.'. We can only create one of the
LLVMConfig.cmake files as the consuming CMake project can only import a
single file. This creates LLVMConfig.cmake and others in the place where
they were previously and where they are for a single-config build.
Differential Revision: https://reviews.llvm.org/D139623
After D137870, LLVM_TARGET_TRIPLE is no longer defined on the runtime
path into compiler-rt. This patch creates a common block of code to set
LLVM_TARGET_TRIPLE equal to the default for both the llvm- and runtime-
paths.
Differential Revision: https://reviews.llvm.org/D138864
This reverts commit bec8a372fc0db95852748691c0f4933044026b25.
This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:
ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64
This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.
This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default,
but using a separate variable allows additional normalization to be
performed if needed.
Differential Revision: https://reviews.llvm.org/D137451
Fix Findzstd CMake to handle shared libraries on OpenBSD correctly.
This userland does not use shared library symlinks without SOVERSION,
so the result of find_library() does not ever end with
zstd_SHARED_LIBRARY_SUFFIX. To work around this, reverse the logic
to compare the result against zstd_STATIC_LIBRARY_SUFFIX and assume
shared library otherwise.
While at it, fix the conditions not to fall back to "result is static
library" path if it actually was recognized as a shared library but
zstd_shared target already existed.
Fixes#59056
Differential Revision: https://reviews.llvm.org/D138361
