diff options
author | Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> | 2020-03-30 15:32:01 -0700 |
---|---|---|
committer | Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> | 2020-04-22 15:13:23 -0700 |
commit | 45526d29a5b2cf126b83ada3991921970007d16f (patch) | |
tree | cc9e5a8fe8a504db2f7dca237a5e7bb228ff779b /lldb/unittests/ScriptInterpreter/Python | |
parent | 2899103108d38215af8aae377cd0e54794278209 (diff) | |
download | llvm-45526d29a5b2cf126b83ada3991921970007d16f.zip llvm-45526d29a5b2cf126b83ada3991921970007d16f.tar.gz llvm-45526d29a5b2cf126b83ada3991921970007d16f.tar.bz2 |
[CMAKE] Provide default location for llvm-lit for out-of-tree users.
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
Diffstat (limited to 'lldb/unittests/ScriptInterpreter/Python')
0 files changed, 0 insertions, 0 deletions