[Lldb-commits] [PATCH] D156270: [lldb][NFCI] Change logic to find clang resource dir in standalone builds

Thu Aug 3 09:03:15 PDT 2023

bulbazord added a comment.

In D156270#4557902 <https://reviews.llvm.org/D156270#4557902>, @mgorny wrote:

> I'm not sure if it was really intended but the new API is kinda horrible, at least for us in Gentoo.
>
> Our install prefix is `/usr/lib/llvm/NN`, whereas clang resource dir is `/usr/lib/clang/NN`.
>
> If I don't override `CLANG_RESOURCE_DIR`, it infers the wrong directory:
> `/usr/lib/llvm/18/lib64/cmake/clang/../../..//lib64/clang/18`.
>
> To get the correct directory, I need to pass:
> `-DCLANG_RESOURCE_DIR="../../../clang/${LLVM_MAJOR}"`
> which is absolutely counterintuitive (the path gets appended to:
> `/usr/lib/llvm/18/lib64/cmake/clang/../../../bin`
> ).
>
> Not saying it's not workable but I'd hardly call that an improvement over the previous API.
>
> CC @tstellar, @paperchalice.

To give some context for my change, downstream for swift there are further changes that involve finding and/or using the clang resource directory. I wanted to take advantage of the new functionality `get_clang_resource_dir` in order to replace the bespoke logic that existed before. Downstream, we had some additional logic to find it again in some cases (which was frustratingly different than what was here before).

If the API is unintuitive or doesn't serve you well, I'm of the opinion that we should change the API. It think it would be a lot easier for your use case if we could tell CMake the absolute path to the clang resource dir instead of having to craft some relative directory that works around the implementation instead of with it.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156270/new/

https://reviews.llvm.org/D156270