[CMake] Ensure `CLANG_RESOURCE_DIR` is respected

[paperchalice]

Summary

This patch ensures all resources are installed into CLANG_RESOURCE_DIR.
Fixes: https://github.com/llvm/llvm-project/issues/59726

[paperchalice]

Use LLVM_LIBRARY_OUTPUT_INTDIR.

[mgorny]

While the general direction seems sound, I suspect this may be a real PITA given that for us:

-DCLANG_RESOURCE_DIR="../../../../lib/clang/${LLVM_MAJOR}"

I'm going to try and see later throughout the week if it's possible to keep that working with this patch.

[mgorny]

Ok, this turned out to be surprisingly painless, at least within our packaging.

However, I'd prefer if someone more experienced looked at the CMake changes.

[MaskRay]

The CMake part of this patch improves the matter. Manually constructed resource dir (many duplicates) string is replace with a library function call.

However, the introduced conditions in C++ code like

std::string path_to_clang_dir = std::string(CLANG_RESOURCE_DIR).empty()
                                    ? "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME
                                      "/clang/" CLANG_VERSION_MAJOR_STRING
                                    : "/foo/bar/bin/" CLANG_RESOURCE_DIR;

makes me uncomfortable.

I wish that we can just replace all manually constructed CLANG_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING with a simple CLANG_RESOURCE_DIR which is guaranteed to be non-empty.

edeaf16f2c2f02d6e43312d48d26d354d87913f3 (2011) added the CMake variable CLANG_RESOURCE_DIR but did not explain why.
In the long term, the CMake variable CLANG_RESOURCE_DIR probably should be removed.

[paperchalice]

In D141907#4094748, @MaskRay wrote:

The CMake part of this patch improves the matter. Manually constructed resource dir (many duplicates) string is replace with a library function call.

However, the introduced conditions in C++ code like

std::string path_to_clang_dir = std::string(CLANG_RESOURCE_DIR).empty()
                                    ? "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME
                                      "/clang/" CLANG_VERSION_MAJOR_STRING
                                    : "/foo/bar/bin/" CLANG_RESOURCE_DIR;

makes me uncomfortable.

I wish that we can just replace all manually constructed CLANG_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING with a simple CLANG_RESOURCE_DIR which is guaranteed to be non-empty.

edeaf16f2c2f02d6e43312d48d26d354d87913f3 (2011) added the CMake variable CLANG_RESOURCE_DIR but did not explain why.
In the long term, the CMake variable CLANG_RESOURCE_DIR probably should be removed.

clang::driver::Driver::GetResourcesPath would be a better choice.

[phosek]

cmake/Modules/GetClangResourceDir.cmake

18

This variable is only used once on the following line, I'd just inline it which is more idiomatic.

19

It's more idiomatic to parse arguments at the start of the function.

19

This is just a nit, but we usually use a prefix like ARGS to make it clear that these are input arguments.

[paperchalice]

• Use clang::driver::Driver::GetResourcesPath
• Use ARG as prefix

[paperchalice]

Ping.

lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp

56

Should be "${CMAKE_INSTALL_BINDIR}/lldb" here, but need another variable in config.h.

[tstellar]

cmake/Modules/GetClangResourceDir.cmake

13

Why is the bin prefix here?

[paperchalice]

cmake/Modules/GetClangResourceDir.cmake

13

See https://clang.llvm.org/doxygen/classclang_1_1driver_1_1Driver.html#acda8dfdf4f80efa84df98157e1779152
GetResourcesPath will return <prefix>/lib/<version> when CLANG_RESOURCE_DIR is empty, <prefix>/bin/CLANG_RESOURCE_DIR otherwise.

[tstellar]

cmake/Modules/GetClangResourceDir.cmake

13

GetResourcesPath calls sys::path::parent_path twice on the path to the clang executable which is going to give you /usr on most Linux systems, so it's returning <prefix>/CLANG_RESOURCE_DIR not <prefix>/bin/CLANG_RESOURCE_DIR.

[tstellar]

cmake/Modules/GetClangResourceDir.cmake

13

Sorry, you are correct. I was looking at the wrong branch. It's really strange that it does that.

[tstellar]

cmake/Modules/GetClangResourceDir.cmake

13

@paperchalice Can you update the description of the CLANG_RESOURCE_DIR cache variable in clang/CMakeLists.txt to mention that the path should be relative to the directory with the clang executable.

[paperchalice]

cmake/Modules/GetClangResourceDir.cmake

13

Already in codebase:

set(CLANG_RESOURCE_DIR "" CACHE STRING
  "Relative directory from the Clang binary to its resource files.")

[tstellar]

Thanks for the patch. I've tested this and it works for my build configuration. LGTM.

[tstellar]

@paperchalice Do you need someone to commit this for you?

[paperchalice]

In D141907#4355228, @tstellar wrote:

@paperchalice Do you need someone to commit this for you?

Sure, I don't have the commit access.

[tstellar]

In D141907#4355229, @paperchalice wrote:

In D141907#4355228, @tstellar wrote:

@paperchalice Do you need someone to commit this for you?

Sure, I don't have the commit access.

What name / email address do you want me to use for the commit author field?

[paperchalice]

In D141907#4361594, @tstellar wrote:

In D141907#4355229, @paperchalice wrote:

In D141907#4355228, @tstellar wrote:

@paperchalice Do you need someone to commit this for you?

Sure, I don't have the commit access.

What name / email address do you want me to use for the commit author field?

Sorry for the late, the information in phabricator is OK, and GetClangResourceDir.cmake is not landed correctly. Ping @tstellar

[protze.joachim]

The review should not be closed, since the patch was reverted and should be recommitted (this time possibly with a reference to this review?)

[paperchalice]

In D141907#4398196, @protze.joachim wrote:

The review should not be closed, since the patch was reverted and should be recommitted (this time possibly with a reference to this review?)

This is recommitted as 0beffb854209a41f31beb18f9631258349a99299, but break some lldb builds, so I created https://reviews.llvm.org/D152225 .