sgraenitz added a comment. In D58193#1398376 <https://reviews.llvm.org/D58193#1398376>, @labath wrote:
> BTW, what's the reason for having super-high-fidelity list of dependencies in > a standalone build? There's a lot of ways to build LLDB (in-tree, standalone, monorepo, single-/multi-config generator) in a lot of contexts (OSs, against build/install-tree) and multiple test frameworks with different requirements (python, lit, unittests). We use a load of conditions to handle all this and they complicate the CMake configuration. Some of these build on wrong assumptions (as we see here with `LLDB_BUILT_STANDALONE` or earlier with `LLDB_TEST_C/CXX_COMPILER`) that always require long explanations. We never test everything and often use quick-fixes that have the tendency to add new quirks. Flakiness of tests add confusion on top of it. IMHO using targets directly in both, in-tree vs. standalone builds, would be a good first step in streamlining the configuration process. We could warn/error early on missing dependencies. We could use generator expressions consistently to query paths of external binaries, Clang headers, etc. In D58193#1399059 <https://reviews.llvm.org/D58193#1399059>, @labath wrote: > Now if we were talking about detecting the available tools and automatically > warning about their absence and/or skipping tests, that would be a different > story, but I don't see anyone proposing that... That's part of it, yes. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58193/new/ https://reviews.llvm.org/D58193 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
