When building lldb in standalone mode, the llvm-nm, llvm-objdump etc target are not available, so only conditionnaly include them.
I did not revert or continue to work on D57233 yet, because it needs a good concept first. LLDB_BUILT_STANDALONE is not the right condition here. What we really want to know is:
- Have LLVM tools/utils been built (LLVM_BUILD_TOOLS/UTILS) when we have a build-tree.
- Have LLVM tools/utils been installed (LLVM_INSTALL_TOOLS/UTILS) when we have an install-tree.
- What tree do we have? I have seen hacks to determine it, but not sure whether there's a clean way.
@sgraenitz: I don't think find_package alone will help you here. LLVMConfig doesn't necessarily tell you what's actually been built and/or installed, but it can tell you what's exported. Here's what I would do:
- List the tools you need for LLDB_TEST_DEPS from LLVM
- For each tool, check to see if it's exported from the LLVM CMake package (this is as simple as checking if it's a target)
- If it's not exported, proceed to the next tool
- If it is exported, use find_program to check if it was built/installed (LLVMConfig should tell you where it is -- LLVM_TOOLS_BINARY_DIR)
- If it is built, add it to LLDB_TEST_DEPS.
- If it's not built, don't add it to LLDB_TEST_DEPS.
I think this should work regardless of if you have a build tree or an install tree. I don't see any logic in here that is specific to one or the other, but if you absolutely do need to check, probably the most reliable way is to check for the existince of the LLVM_BUILD_* variables. I think the install tree also has a variable LLVM_INSTALL_PREFIX, so that could be another way to check.
BTW, what's the reason for having super-high-fidelity list of dependencies in a standalone build? I know that they're important for in-tree builds, as that makes sure everything is built when you run "check-lldb". However, that's isn't going to help you with standalone builds. The binaries are already there, or they aren't, and there's nothing we can do to change that. I'd consider just removing all non-lldb targets from the deps list when in standalone mode.
I think it's useful to be able to fully test lldb if you have all the available tools even if it's built standalone. This is especially relevant for swift-lldb, which more often than not is built standalone because swift is often built standalone. I'm generally not in favor of keeping things around only because somebody downstream uses it, but I can see the usefulness for people who work on upstream LLDB as well. I'm not sure if other people feel the same way though.
I certainly agree with that, but I don't see how fiddling with LLDB_TEST_DEPS is going to help testing at all. AFAICT, all it does it set's up the dependencies in the cmake graph. That is not going to help you run the tests. If the tools are there, the tests will run fine; if they aren't the tests will fail.
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...
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.
That's part of it, yes.
Could you check what's the state of the master branch? It's possible some of the changes we've been talking about didn't make the 8.0 cut. We still have the time to cherry-pick it over, but it's going to run out soon.
You build against an installed LLVM and you want to run LLDB tests? AFAIK you need to:
- configure LLVM with LLVM_INSTALL_UTILS=ON
- configure standalone LLDB with LLVM_EXTERNAL_LIT=/path/to/llvm-build-tree/bin/llvm-lit
However, llc and dsymutil are tools and they should not be affected.
If you don't want to run the test suite, pass LLDB_INCLUDE_TESTS=OFF.
Maybe @mgorny can add some info here?
@serge-sans-paille After all, it appears to me that your issue is caused by something else, but if this change fixes it, I am not against taking it for now. It shouldn't do any harm. Please get in touch with @hans if this is really relevant for release_80.
However, please note that your patch base is not up-to-date with master  or release_80  branches. The meanwhile changes shouldn't affect the dsymutil or llc targets, but maybe it's a hint towards the actual problem.
Also note that the lines you want to modify are there since May  and September  respectively, so it's been this way already in the 7.0 release.
(I am off till early March and will only check my inbox rarely. Hope everything's gonna work out well.)