Other LLVM projects use the suffix `-depends` for the test dependencies,
however LLDB uses `-deps` and seems to be the only project under the
LLVM to do so.
In order to make the projects more homogeneous, switch all the
references to `lldb-test-deps` to `lldb-test-depends`.
Additionally, provide a compatibility target with the old name and
depending on the new name, in order to not break anyone workflow.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D102889
This reapplies 7df4eaaa93/D96202, which was reverted due to issues on
windows. These were caused by problems in the computation of the liblldb
directory, which was fixed by D96779.
The original commit message was:
Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.
A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.
One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.
A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").
Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.
Differential Revision: https://reviews.llvm.org/D96202
Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.
A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.
One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.
A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").
Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.
Differential Revision: https://reviews.llvm.org/D96202
Replace the dotest command line options and various cmake variables,
which are used for passing the locations of llvm tools to the API tests
with a single variable, which points to the directory these tools are
placed in. Besides reducing repetition, this also makes things more
similar to how "normal" llvm tests are configured.
Differential Revision: https://reviews.llvm.org/D95261
Test runs log some of their output to files inside the LLDB session dir. This
session dir is shared between all tests, so all the tests have to make sure they
choose a unique file name inside that directory. We currently choose by default
`<test-class-name>-<test-method-name>` as the log file name. However, that means
that if not every test class in the test suite has a unique class name, then we
end up with a race condition as two tests will try to write to the same log
file.
I already tried in D83767 changing the format to use the test file basename
instead (which we already require to be unique for some other functionality),
but it seems the code for getting the basename didn't work on Windows.
This patch instead just changes that dotest stores the log files in the build
directory for the current test. We know that directory is unique for this test,
so no need to generate some unique file name now. Also removes all the
environment vars and parameters related to the now unused session dir.
The new log paths now look like this for a failure in 'TestCppOperators`:
```
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dwarf/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dsym/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_gmodules/Failure.log
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92498
They are currently not being set correctly for the case of multi-config generators like XCode and VS. There's also a typo in one of the cmake files.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D87466
This patch is a big sed to rename the following variables:
s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
s/PYTHON_RPATH/Python3_RPATH/g
I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.
Differential revision: https://reviews.llvm.org/D85976
[intel-pt] Improve the way the test determines whether to run
- Now I'm creating a default value for the new test parameter
- I fixed a small mistake in the skipping logic of the test
... I forgot to clear the cmake cache when testing my diff
Summary:
@labath raised a concern on the way I was skipping this test. I think that was
fair and I found a better way.
Now I'm skipping if the CMAKE flag LLDB_BUILD_INTEL_PT is false.
I added an enabled_plugins entry in the dotest configuration, which gets
set by lit or lldb-dotest. The only available plugin right now is
'intel-pt', but I imagine it will be useful in the future for other
kinds of plugins that get determined at configuration time. I didn't
want to add a new argument option --enable-intel-pt or something or the
sort, as it wouldn't be useful for other cases.
Reviewers: labath, clayborg
Subscribers: lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77452
Ideally we'd want all shebangs to be configurable, but that's not a
viable solution. Given that lldb-dotest is already configured, we might
as well make sure it uses the correct interpreter.
Differential revision: https://reviews.llvm.org/D76167
Summary: Currently, lldb-repro is placed in the wrong location for multi-configuration generators. For example, in the case of VS, it is placed in a directory $(Configuration) instead of in each of Debug, Release, etc.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74148
Summary:
When the generator used for CMake is a multi-configuration generator (such as VS), the arguments passed to dotest are not currently configured correctly. There are a couple of issues:
1) The per-configuration files are all generated for the same configuration since the for loop overwrites the properties
2) Not all of the parameters are configured in the lit cfg, so they end up with %(build_mode)s as configuration and they point to non-existent paths
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74093
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
Rather than serializing every argument through LLDB_TEST_COMMON_ARGS, we
can pass some of them directly using their CMake variable. Although this
does introduce some code duplication between lit's site config and the
lldb-dotest utility, it also means that it becomes easier to override
these values (WIP).
I often use `ninja lldb-test-deps` to build all the test dependencies
before running a subset of the tests with `lit --filter`. This
functionality seems to break relatively often because test dependencies
are tracked in an ad-hoc way acrooss cmake files. This patch adds a
helper function `add_lldb_test_dependency` to unify test dependency
tracking by adding dependencies to lldb-test-deps.
Differential revision: https://reviews.llvm.org/D68612
llvm-svn: 373996
Currently, lit tests don't set neither the module cache for building
inferiors nor the module cache used by lldb when running tests.
Furthermore, we have several places where we rely on the path to the
module cache being always the same, rather than passing the correct
value around. This makes it hard to specify a different module cache
path when debugging a a test.
This patch reworks how we determine and pass around the module cache
paths and fixes the omission on the lit side. It also adds a sanity
check to the lit and dotest suites.
Differential revision: https://reviews.llvm.org/D66966
llvm-svn: 370394
This patch removes the -q (quiet) flag and changing the default
behavior. Currently the flag serves two purposes that are somewhat
contradictory, as illustrated by the difference between the argument
name (quiet) and the configuration flag (parsable). On the one hand it
reduces output, but on the other hand it prints more output, like the
result of individual tests. My proposal is to guard the extra output
behind the verbose flag and always print the individual test results.
Differential revision: https://reviews.llvm.org/D66837
llvm-svn: 370226
Summary:
Allow to run the test suite when building LLDB Standalone with Xcode against a provided LLVM build-tree that used a single-configuration generator like Ninja.
So far both test drivers, lit-based `check-lldb` as well as `lldb-dotest`, were looking for test dependencies (clang/dsymutil/etc.) in a subdirectory with the configuration name (Debug/Release/etc.). It was implicitly assuming that both, LLDB and the provided LLVM used the same generator. In practice, however, the opposite is quite common: build the dependencies with Ninja and LLDB with Xcode for development*. With this patch it becomes the default.
(* In fact, it turned out that the Xcode<->Xcode variant didn't even build out of the box. It's fixed since D62879)
Once this is sound, I'm planning the following steps:
* add stage to the [lldb-cmake-standalone bot](http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/) to build and test it
* update `Building LLDB with Xcode` section in the docs
* bring the same mechanism to swift-lldb
* fade out the manually maintained Xcode project
On macOS build and test like this:
```
$ git clone https://github.com/llvm/llvm-project.git /path/to/llvm-project
$ cd /path/to/lldb-dev-deps
$ cmake -GNinja -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi" /path/to/llvm-project/llvm
$ ninja
$ cd /path/to/lldb-dev-xcode
$ cmake -GXcode -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLDB_BUILD_FRAMEWORK=Off -DLLVM_DIR=/path/to/lldb-dev-deps/lib/cmake/llvm -DClang_DIR=/path/to/lldb-dev-deps/lib/cmake/clang /path/to/llvm-project/lldb
$ xcodebuild -configuration Debug -target check-lldb
$ xcodebuild -configuration Debug -target lldb-dotest
$ ./Debug/bin/lldb-dotest
```
Reviewers: JDevlieghere, jingham, xiaobai, stella.stamenova, labath
Reviewed By: stella.stamenova
Subscribers: labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62859
llvm-svn: 362803
In order to debug a failing python test, you need to debug Python
instead of the wrapper. For a while I've been adding and removing this,
but I think it could be useful for everyone.
llvm-svn: 357554
Without that, dotest.py would be executed with the default python
interpreter, which may not be the same one that lldb is built with.
This still requires the user do know which python interpreter to use
when running lldb-dotest, but now he is at least able to choose it, if
he knows which one to use.
llvm-svn: 354105
This patch restructures part of LLDB's testing configuration:
1. I moved the test dependencies up the chain so every dotest dependency
becomes a lit dependency as well. It wouldn't make sense for dotest to
have other dependencies when it's being run by lit. Lit on the other
hand can still specify extra dependencies.
2. I replaced as much generator expressions with variables as possible.
This is consistent with the rest of LLVM and doesn't break generators
that support multiple targets (MSVC, Xcode). This wasn't a problem
before, but now we need to expand the dotest arguments in the lit
configuration and there's only one test suite even with multiple
targets.
3. I moved lldb-dotest into it's own directory under utils since there's
no need anymore for it to located under `test/`.
Differential revision: https://reviews.llvm.org/D46334
llvm-svn: 331463
Daniel Rodríguez Troitiño