[lldb][CMake] Infer `Clang_DIR` if not passed explicitly

[sgraenitz]

Summary

If we only get LLVM_DIR and find Clang in the same provided build-tree, automatically infer Clang_DIR like this:

LLVM_DIR = /path/to/build-llvm/lib/cmake/llvm
Clang_DIR = /paht/to/build-llvm/lib/cmake/clang

[compnerd]

lldb/cmake/modules/LLDBStandalone.cmake

6

What happens in the standalone clang build scenario? Can I ask what is the motivation for this change? I think it is better to require that the user pass the path, as that is an explicit dependency of LLDB.

[sgraenitz]

lldb/cmake/modules/LLDBStandalone.cmake

6

I don't think there's any side-effects on Clang standalone builds. Is that what you mean with "standalone clang build scenario"?

I would like top prevent people from writing custom build scripts on top of CMake. Passing a number of very similar paths to CMake, e.g. each time we want to generate a Xcode project for development, this option seems to become compelling quickly. This patch makes standalone configurations simpler. Basically, it provides a default value. I doesn't cut down functionality.

You can still explicitly pass any path you want. This branch will then not be taken.

[compnerd]

lldb/cmake/modules/LLDBStandalone.cmake

6

I think that the build fragmentation has caused a larger problem, and I would like to avoid that. The standalone build scenario is:

build/llvm
build/clang
build/lldb

In this case, ../clang does not exist (../../clang/lib/cmake/clang does). I think what I would suggest instead is adding a cache file that has the configuration parameters setup already.

[sgraenitz]

lldb/cmake/modules/LLDBStandalone.cmake

6

For the scenario you describe, can you point me to any documentation that describes it or a bot that builds it?

I think what I would suggest instead is adding a cache file that has the configuration parameters setup already.

How would your cache file look like?

[labath]

lldb/cmake/modules/LLDBStandalone.cmake

6

For the scenario you describe, can you point me to any documentation that describes it or a bot that builds it?

I think a lot of linux distributions which want to provide llvm,clang,etc. as separate packages build in this way. And those that don't, they'd probably want to build it that way, but they can't do it because it doesn't work for them for one reason or another (the standalone builds are always a bit behind, because the devs usually just build everything monolithically). I know at least gentoo builds llvm, clang and lldb standalone. Maybe @mgorny has a better overview of what other distros do...

[sgraenitz]

Change comment and condition to only infer Clang_DIR if it exists.

[sgraenitz]

lldb/cmake/modules/LLDBStandalone.cmake

6

Fair enough. So, in this case we just can't make a reasonable guess right?

Maybe we can still simplify the scenario for a single provided build-tree with LLVM and Clang? How could we do it?
I changed the comment and the condition to only infer the directory if it exists. Is that acceptable?

[sgraenitz]

What do you think?

[labath]

Making it so that the clang is automatically found it if happens to be next to llvm seems like a reasonable thing to me. I have no idea what would be the canonical cmake way to do that...

[sgraenitz]

Update documentation to mention multiple provided build trees and the usage of Clang_DIR

[sgraenitz]

In D65798#1618609, @labath wrote:

Making it so that the clang is automatically found it if happens to be next to llvm seems like a reasonable thing to me. I have no idea what would be the canonical cmake way to do that...

"the canonical cmake way" good question! It turns out that, providing another hint for find_package(Clang ...) does exactly that: it sets Clang_DIR to the first path where it found Clang. If we do not attach great importance to the status message, we could do:

find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang NO_CMAKE_FIND_ROOT_PATH)

# Clang_DIR is defined now even if the ${LLVM_DIR}/../clang fallback was used

[sgraenitz]

Achieve the same via extra HINT to find_package(Clang ...)

[labath]

I'm happy with this, and it looks very nice and idiomatic, but maybe wait for @compnerd a bit, as he had some reservations about the whole thing..

lldb/cmake/modules/LLDBStandalone.cmake

 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
-find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
 
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
 set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
 
 set(lit_file_name "llvm-lit")
 if(CMAKE_HOST_WIN32 AND NOT CYGWIN)

lldb/docs/resources/build.rst

 ::
 
   > ninja lldb
 
 Standalone builds
 *****************
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
 directory in the source-tree. Note that we leave out LLDB here and only include
 Clang. Then we build the ``ALL`` target with ninja:
 
 ::
 
   > cmake -B /path/to/llvm-build -G Ninja \
           -DLLVM_ENABLE_PROJECTS=clang \
           [<more cmake options>] /path/to/llvm-project/llvm
   > ninja
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ninja \
           -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-          -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
           [<more cmake options>] /path/to/llvm-project/lldb
   > ninja lldb
 
 .. note::
 
    #. The ``-B`` argument was undocumented for a while and is only officially
       supported since `CMake version 3.14
       <https://cmake.org/cmake/help/v3.14/release/3.14.html#command-line>`_
> cmake -B /path/to/llvm-build -G Ninja \
           -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-base.cmake \
           -DLLVM_ENABLE_PROJECTS="clang;libcxx" \
           llvm-project/llvm
   > ninja -C /path/to/llvm-build
 
   > cmake -B /path/to/lldb-build \
           -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
           -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-          -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
           llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb
 
 .. note::
 
    The ``-B`` argument was undocumented for a while and is only officially
    supported since `CMake version 3.14