Age | Commit message (Collapse) | Author | Files | Lines |
|
dependencies too"
This reverts commit 9f3081dc6fe8447e85741865846840bc491866e5.
Broke clangd buildbots in
https://lab.llvm.org/buildbot/#/builders/131/builds/38935.
|
|
Fixes: https://github.com/llvm/llvm-project/issues/59844
Differential Revision: https://reviews.llvm.org/D141047
|
|
Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:
CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
Unknown CMake command "cmake_push_check_state".
Call Stack (most recent call first):
cmake/modules/LLDBConfig.cmake:52 (find_package)
cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
CMakeLists.txt:28 (include)
Gentoo Bug: https://bugs.gentoo.org/880065
Differential Revision: https://reviews.llvm.org/D137555
|
|
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
|
|
This reverts commit 88d7508dc479210f07abccb17f0194b66264b125.
It's reported to break builds when symlinking other projects inside
the `tools` directory.
|
|
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
|
|
Take the library target out of `generate_protos` function so the caller
can decide where to layer the library using the source generated from
the function.
Fixes: https://github.com/llvm/llvm-project/issues/58075
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D135712
|
|
This reverts commit f7a33090a91015836497c75f173775392ab0304d.
Unfortunately this causes a number of failures that didn't show up in my
local build.
|
|
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
|
|
This was in CMake syntax generation, so we didn't catch it eval time.
Follow up from D117973
|
|
Firstly, we we make an additional GNUInstallDirs-style variable. With
NixOS, for example, this is crucial as we want those to go in
`${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir
of the "regular" libdir, which is installed even when no one needs to do
any development.
Secondly, we make *Config.cmake robust to absolute package install
paths. We for NixOS will in fact be passing them absolute paths to make
the `${dev}` vs `${out}` distinction mentioned above, and the
GNUInstallDirs-style variables are suposed to support absolute paths in
general so it's good practice besides the NixOS use-case.
Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other
install dirs are.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D117973
|
|
FindLibEdit uses pkg-config to find the necessary flags, but this may break with cross-compilation,
because the PkgConfig module in CMake doesn't respect the SYSROOT specified in a toolchain file.
Instead of taking the parameters from pkg-config for granted, we check whether our compiler can
actually include and link against the library.
Fixes #55445
Fixes #55671
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D126450
|
|
This way, we could use it for LLVM_ENABLE_PROJECTS too if desired.
Differential Revision: https://reviews.llvm.org/D125121
|
|
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124673
|
|
The previous case was a tautology - this is probably what was intended.
Differential Revision: https://reviews.llvm.org/D124072
|
|
Sometimes, we could be building for a platform where we don't link
compiler-rt, so being able to figure out the right compiler-rt suffix
isn't necessary, but we shouldn't fail the build.
|
|
This patch uses CMAKE_OSX_SYSROOT, which should contain the SDK path
that we're building against on Apple platforms, to determine which
platform we are compiling for and set the compiler-rt suffix accordingly.
Differential Revision: https://reviews.llvm.org/D122161
|
|
When using COMPILER_RT_USE_BUILTINS_LIBRARY=ON and clang-cl there
where several places where it didn't work as expected.
First -print-libgcc-file-name has to be prefixed with /clang:
Then the regex that matched the builtins library was wrong because
the builtins library is called clang_rt.builtins_<arch>.lib
and the regex only matched libclang_rt.builtins_arch.a
With this commit you can use a runtime build on Windows with this
option enabled.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D120698
|
|
|
|
runtime libs and llvm
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
|
|
libs and llvm"
This reverts commit 4af11272f57a4a6fed2932e9e0857b2c1a707c51.
|
|
and llvm
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.
This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
|
|
This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.
It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.
Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314
Differential Revision: https://reviews.llvm.org/D117617
|
|
@phosek mentioned others might want it reST for consistency. As I
personally do not like Markdown at all and just did the "usual GitHub
read-me thing" out of habit, I am more than happy to oblige.
Also fix the typos found in the original.
Reviewed By: phosek, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116524
|
|
See the docs in the new function for details.
I think I found every instance of this copy pasted code. Polly could
also use it, but currently does something different, so I will save the
behavior change for a future revision.
We get the shared, non-installed CMake modules following the pattern
established in D116472.
It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.
Reviewed By: beanz, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116521
|
|
Now that I am adding more things there, I thought it prudent to document
what should and should not go there, and how it is used.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D116524
|
|
This allows their reuse across projects. The name of the module
is intentionally generic because we would like to move more platform
checks there.
Differential Revision: https://reviews.llvm.org/D115276
|
|
There was one more reference the word "install" I forgot to remove.
Follow-up to bde561c4813952847112600e5efe72d9015556f7 /
https://reviews.llvm.org/D115746
|
|
It is likely to become used again, if other projects want their own per-project
install directory variables. `install` is removed from the name since it is not inherently about installing.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115746
|
|
If Clang is set up to link directly against libunwind (via the
--unwindlib option, or the corresponding builtin default option),
configuring libunwind will fail while bootstrapping (before the
initial libunwind is built), because every cmake test will
fail due to -lunwind not being found, and linking the shared library
will fail similarly.
Check if --unwindlib=none is supported, and add it in that case.
Using check_c_compiler_flag on its own doesn't work, because that only
adds the tested flag to the compilation command, and if -lunwind is
missing, the linking step would still fail - instead try adding it
to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work.
This avoids having to pass --unwindlib=none while building libunwind.
Differential Revision: https://reviews.llvm.org/D112126
|
|
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
|
|
This reverts commit 0eed292fbae22a8856682b07e1cb968424b49941, there
are compiler-rt build failures that appear to have been introduced
by this change.
|
|
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
|