[Lldb-commits] [lldb] [lldb] Split TestGdbRemoteFork test to avoid timeout (PR #129614)

[Pavel Labath via lldb-commits]

labath wrote:

> > You could make the test binary a cmake dependency, see `lldb/test/CMakeLists.txt`. Perhaps in:
> > ```
> > if(TARGET lldb-server)
> >   add_lldb_test_dependency(lldb-server)
> > endif()
> > ```
> 
> Just so it's clear, it is not lldb-server itself that is the slow dependency, but the cpp file in the test directory. I think you mean we could create a new binary from the test file.
> 
> Pulling out the [cpp file](https://github.com/llvm/llvm-project/blob/main/lldb/test/API/tools/lldb-server/main.cpp) into a separate tool might work. I don't know if there are any issues trying that. It's now building with the just-built clang binaries hooks into the dotest build system which seems to allow more flexibility in building it in different ways at test runtime (although I'm not sure we actually rely on that flexibility).

I think that would be a problem for remote tests (where the architecture of the binary needs to be different from the lldb architecture) and would be a significant change in how the tests work. I really wouldn't want to go in that direction. What I could imagine is building the binary in the "static" `setUpClass` method so that it's only built once per test, but I suspect that even that could run be fairly tricky. It might be easiest to just merge some trivial tests. Targeted tests are sort of a "best practice", but there's obviously a tradeoff between that and test startup time, and I think some of these are going too far. For example, I don't think that `test_Hg_fails_on_another_pid` and `test_Hg_fails_on_zero_pid` really need to be separate tests (I'm not even sure we really need both of those).

https://github.com/llvm/llvm-project/pull/129614