[Lldb-commits] [lldb] fc04749 - [lldb] Fix detection of existing libcxx

Felipe de Azevedo Piovezan via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 12 09:34:38 PDT 2022


Author: Felipe de Azevedo Piovezan
Date: 2022-09-12T12:34:11-04:00
New Revision: fc04749957f17f42b1eab538fa3e68857034facb

URL: https://github.com/llvm/llvm-project/commit/fc04749957f17f42b1eab538fa3e68857034facb
DIFF: https://github.com/llvm/llvm-project/commit/fc04749957f17f42b1eab538fa3e68857034facb.diff

LOG: [lldb] Fix detection of existing libcxx

The CMake variable LLDB_HAS_LIBCXX is passed to
`llvm_canonicalize_cmake_booleans`, which transforms TRUE/FALSE into
'1'/'0'. It also transforms undefined variables to '0'.

In particular, this means that the configuration script for LLDB API's
test always has _some_ value for the `has_libcxx` configuration:

```
config.has_libcxx = '@LLDB_HAS_LIBCXX@'
```

When deciding whether a libcxx exist, the testing scripts would only
check for the existence of `has_libcxx`, but not for its value. In other
words, because `if ('0')` is true in python we always think there is a
libcxx.

This was caught once D132940 was merged and most tests started to use
libcxx by default if `has_libcxx` is true.  Prior to that, no failures
were seen because only tests are marked with
`@add_test_categories(["libc++"])` would require a libcxx, and these
would be filtered out on builds without the libcxx target. Furthermore,
the MacOS bots always build libcxx.

We fix this by making `has_libcxx` a boolean (instead of a string) and
by checking its value in the test configuration.

Differential Revision: https://reviews.llvm.org/D133639

Added: 
    

Modified: 
    lldb/test/API/lit.cfg.py
    lldb/test/API/lit.site.cfg.py.in

Removed: 
    


################################################################################
diff  --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 51309d5d384ae..e9a4e36be1d6a 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -171,10 +171,11 @@ def delete_module_cache(path):
   dotest_cmd += ['--env', 'LLVM_TOOLS_DIR=' + config.llvm_tools_dir]
 
 # If we have a just-built libcxx, prefer it over the system one.
-if is_configured('has_libcxx') and platform.system() != 'Windows':
-  if is_configured('llvm_include_dir') and is_configured('llvm_libs_dir'):
-    dotest_cmd += ['--libcxx-include-dir', os.path.join(config.llvm_include_dir, 'c++', 'v1')]
-    dotest_cmd += ['--libcxx-library-dir', config.llvm_libs_dir]
+if is_configured('has_libcxx') and config.has_libcxx:
+  if platform.system() != 'Windows':
+    if is_configured('llvm_include_dir') and is_configured('llvm_libs_dir'):
+      dotest_cmd += ['--libcxx-include-dir', os.path.join(config.llvm_include_dir, 'c++', 'v1')]
+      dotest_cmd += ['--libcxx-library-dir', config.llvm_libs_dir]
 
 # Forward ASan-specific environment variables to tests, as a test may load an
 # ASan-ified dylib.

diff  --git a/lldb/test/API/lit.site.cfg.py.in b/lldb/test/API/lit.site.cfg.py.in
index d10a91d2af1ed..ca8354ddc069a 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -31,7 +31,7 @@ config.lldb_executable = lit_config.substitute('@LLDB_TEST_EXECUTABLE@')
 config.test_arch = '@LLDB_TEST_ARCH@'
 config.test_compiler = lit_config.substitute('@LLDB_TEST_COMPILER@')
 config.dsymutil = lit_config.substitute('@LLDB_TEST_DSYMUTIL@')
-config.has_libcxx = '@LLDB_HAS_LIBCXX@'
+config.has_libcxx = @LLDB_HAS_LIBCXX@
 # The API tests use their own module caches.
 config.lldb_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_LLDB@", "lldb-api")
 config.clang_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_CLANG@", "lldb-api")


        


More information about the lldb-commits mailing list