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
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
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
Petr Hosek