Replace the custom libomp_check_linker_flag() implementation with llvm_check_compiler_linker_flag() from the common cmake utils. Due to the way the custom implementation is implemented (capturing output from an entire nested cmake invocation) it can easily end up incorrectly detection flags as unavailable, e.g. because error, unknown or similar occurs inside compiler flags, the directory name, etc.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The openmp project may not be always built by LLVM, especially the host library libomp. Using llvm_check_compiler_linker_flag may cause CMake error if users don't use LLVM.
@tianshilei1992 This function is part of the common cmake utilities that openmp already requires, not the LLVM cmake utilities.
I did miss adding the necessary include though.
Hmm, okay. That is unexpected TBH because openmp is supposed to support to be built as a standalone project. For example, we do have a standalone release for OpenMP (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.2/openmp-16.0.2.src.tar.xz). https://reviews.llvm.org/D130545 definitely broke it.
I'm not as familiar with libomp. Are we allowed to have explicit dependencies on LLVM? I know libomptarget requires LLVM, but I'm pretty sure libomp doesn't share the same rules. Worst case scenario we just copy the llvm_check_compiler_linker_flag.
Nowadays all standalone builds (including the one for openmp) require at least the cmake tarball as well. This is the case for both projects like clang and runtimes like compiler-rt. I don't like this either, but it's the current situation...
I personally wouldn't mind just copying the relevant file into the openmp project, it just seems to go against the overall trend in the monorepo.
Okay, since it is already broken, it has nothing to do with this patch. We can revisit the cmake issue later.