forked from OSchip/llvm-project
45526d29a5
Several external build users contain some heuristics for finding llvm-lit. There are several cases we need to worry about: - External builds against a build tree (with LLVM_BUILD_UTILS) - External builds against an install tree (with LLMV_BUILD_UTIL and LLVM_INSTALL_UTILS) - External builds against some location which doesn't have an llvm-lit, but llvm-lit is available through some other means, such as an available source tree, or a packager provided llvm-lit. For the third case, LLVM_EXTERNAL_LIT suffices, but in other cases there's no standard way to find llvm-lit. It seems like each user cooks their own heuristics: - clang tries to look in the LLVM source tree, and failing that falls back to looking for a packaged llvm-lit. - libcxx tries to look in the LLVM source tree, which might come from llvm-config or be explicitly specified. This patch is a first stop to solving this by providing a default location for llvm-lit using LLVM_DEFAULT_EXTERNAL_LIT. The expectation is that future patches can clean up users like clang and libcxx to rely on this mechanism for out-of-tree builds. Differential Revision: https://reviews.llvm.org/D77110 |
||
|---|---|---|
| .. | ||
| modules | ||
| platforms | ||
| README | ||
| config-ix.cmake | ||
| config.guess | ||
| dummy.cpp | ||
| nsis_icon.ico | ||
| nsis_logo.bmp | ||
README
See docs/CMake.html for instructions on how to build LLVM with CMake.