[CMake] Add special case for processing LLDB_DOTEST_ARGS

[sgraenitz]

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 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

[stella.stamenova]

I don't think that this would apply very well to Visual Studio with the current change because it is likely that if you are using VS to build LLDB, you also used VS to build the dependencies. Even for xcode, I am sure that there are people who build the dependencies standalone with xcode and then are building LLDB standalone with xcode, so any change that absolutely treats the scenario as one or the other is going to break someone.

I think a better change would be to allow a parameter to be passed like your suggested LLDB_PROVIDED_NINJA_BUILD_TREE=On (except don't use Ninja in the name, how the tree came about is not important and it could also be make or a tree copied from another build) and then use that and LLDB_BUILT_STANDALONE for the pivot. Then if someone provides the new parameter, they know what they are doing and we can expect it to work for Xcode and VS both.

[labath]

LLDB_PROVIDED_NINJA_BUILD_TREE=On

An even better option would be to get the llvm build to export the fact whether it was built with a multi-config generator or not. Then the user wouldn't have to provide anything, and things would "just work". :)

[sgraenitz]

Thanks for your feedback. I should have mentioned that this is pretty much a draft. For now I was happy it works at all.

In D62859#1529498, @stella.stamenova wrote:

I don't think that this would apply very well to Visual Studio with the current change because it is likely that if you are using VS to build LLDB, you also used VS to build the dependencies.

Good point

I think a better change would be to allow a parameter to be passed like your suggested LLDB_PROVIDED_NINJA_BUILD_TREE=On (except don't use Ninja in the name, how the tree came about is not important and it could also be make or a tree copied from another build) and then use that and LLDB_BUILT_STANDALONE for the pivot. Then if someone provides the new parameter, they know what they are doing and we can expect it to work for Xcode and VS both.

Yes, then it's either that or what Pavel proposed.

In D62859#1529666, @labath wrote:

LLDB_PROVIDED_NINJA_BUILD_TREE=On

An even better option would be to get the llvm build to export the fact whether it was built with a multi-config generator or not. Then the user wouldn't have to provide anything, and things would "just work". :)

Yes, I will check if I can store it in LLVMConfig.cmake

[sgraenitz]

Chose the replacement for remaining matches of CMAKE_CFG_INTDIR depdending on LLVM_CONFIGURATION_TYPES

[stella.stamenova]

lldb/lit/CMakeLists.txt

16

It looks like you need the update here also. Is there a way to share the logic between the two cmake files?

You probably no longer need the xcode pivot either, right?

[sgraenitz]

Patch the replacement logic also in lit/CMakeLists.txt

[sgraenitz]

After figuring out D62879 that came up on the way, this wasn't too complicated indeed. I put the patch for exporting LLVM_CONFIGURATION_TYPES here: D62878

lldb/lit/CMakeLists.txt

16

Thanks for catching this one! Ok deal, I remove the Xcode restriction and you run a test with VS? ;)

[stella.stamenova]

lldb/lit/CMakeLists.txt

16

I can run some tests with VS, probably tomorrow though.

[sgraenitz]

Remove Xcode restriction and polish

[sgraenitz]

lldb/lit/CMakeLists.txt

10

I will have to fix this. We only need one match here.

Is there a way to share the logic between the two cmake files?

Unfortunately they're slightly different. lldb-dotest generates the actual driver scripts. Here, we only write the (one) cfg file and it relies on replacements of %(build_mode)s at runtime in ( see https://github.com/llvm/llvm-project/blob/6fc4c1cc54/lldb/lit/Suite/lit.site.cfg.in#L35).

[sgraenitz]

Unfortunately lit is a little more complicated

[sgraenitz]

Polishing

[sgraenitz]

This comment was removed by sgraenitz.

lldb/lit/CMakeLists.txt

 # Test runner infrastructure for LLDB. This configures the LLDB test trees
 # for use by Lit, and delegates to LLVM's lit test handlers.
 
+# LLVM_BUILD_MODE is used in lit.site.cfg
 if (CMAKE_CFG_INTDIR STREQUAL ".")
   set(LLVM_BUILD_MODE ".")
 else ()
   set(LLVM_BUILD_MODE "%(build_mode)s")
 endif ()
 
 if (CMAKE_SIZEOF_VOID_P EQUAL 8)
   set(LLDB_IS_64_BITS 1)
 endif()
 
 get_property(LLDB_DOTEST_ARGS GLOBAL PROPERTY LLDB_DOTEST_ARGS_PROPERTY)
+set(dotest_args_replacement ${LLVM_BUILD_MODE})
 
+if(LLDB_BUILT_STANDALONE)
+  # In paths to our build-tree, replace CMAKE_CFG_INTDIR with our configuration name placeholder.
+  string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} config_runtime_output_dir ${LLVM_RUNTIME_OUTPUT_INTDIR})
+  string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
+
+  # Remaining ones must be paths to the provided LLVM build-tree.
+  if(LLVM_CONFIGURATION_TYPES)
+    # LLDB uses single-config; LLVM multi-config; pick one and prefer Release types.
+    # Otherwise, if both use multi-config the default is fine.
+    if(NOT CMAKE_CONFIGURATION_TYPES)
+      if(RelWithDebInfo IN_LIST LLVM_CONFIGURATION_TYPES)
+        set(dotest_args_replacement RelWithDebInfo)
+      elseif(Release IN_LIST LLVM_CONFIGURATION_TYPES)
+        set(dotest_args_replacement Release)
+      else()
+        list(GET LLVM_CONFIGURATION_TYPES 0 dotest_args_replacement)
+      endif()
+    endif()
+  else()
+    # Common case: LLVM used a single-configuration generator like Ninja.
+    set(dotest_args_replacement ".")
+  endif()
+endif()
+
+string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
 
 list(APPEND LLDB_TEST_DEPS
   LLDBUnitTests
   dsymutil
   lit-cpuid
   llc
   lldb
   lldb-test

lldb/utils/lldb-dotest/CMakeLists.txt

 # Make lldb-dotest a custom target.
 add_custom_target(lldb-dotest)
 add_dependencies(lldb-dotest ${LLDB_TEST_DEPS})
 set_target_properties(lldb-dotest PROPERTIES FOLDER "lldb utils")
 
 get_property(LLDB_DOTEST_ARGS GLOBAL PROPERTY LLDB_DOTEST_ARGS_PROPERTY)
 
-# Generate wrapper for each build mode.
-if(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
+# Generate lldb-dotest Python driver script for each build mode.
+if(LLDB_BUILT_STANDALONE)
+  foreach(config_type ${CMAKE_CONFIGURATION_TYPES})
+    # In paths to our build-tree, replace CMAKE_CFG_INTDIR with our actual configuration names.
+    string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} config_runtime_output_dir ${LLVM_RUNTIME_OUTPUT_INTDIR})
+    string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
+
+    # Remaining ones must be paths to the provided LLVM build-tree.
+    if(${config_type} IN_LIST LLVM_CONFIGURATION_TYPES)
+      # Multi-configuration generator like Xcode (with a matching config).
+      string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
+    else()
+      # Single-configuration generator like Ninja.
+      string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
+    endif()
+
+    configure_file(
+      lldb-dotest.in
+      ${config_runtime_output_dir}/lldb-dotest @ONLY
+    )
+  endforeach()
+elseif(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
   foreach(LLVM_BUILD_MODE ${CMAKE_CONFIGURATION_TYPES})
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
     configure_file(
       lldb-dotest.in
       ${LLDB_DOTEST_DIR}/lldb-dotest
       )
   endforeach()
 else()
   configure_file(
     lldb-dotest.in
     ${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-dotest
     )
 endif()