[clang] RFC: [cmake] Export CLANG_RESOURCE_DIR in ClangConfig (PR #97197)
Chris B via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 12 08:17:04 PDT 2024
llvm-beanz wrote:
> I think at the time we started doing this, Clang's builtin includes lookup basically did `$dirname($0)/../lib/llvm-$version/clang/$version/include`. So when building `include-what-you-use` in a separate tree, the resulting binary didn't have the builtin headers in the right place, and we wouldn't be able to run tests.
`clang::Driver` has this method which allows you to specify the starting path for the clang installation to use for the resource lookup.
```c++
/// Takes the path to a binary that's either in bin/ or lib/ and returns
/// the path to clang's resource directory.
static std::string GetResourcesPath(StringRef BinaryPath,
StringRef CustomResourceDir = "");
```
> We support three build modes:
>
> * as part of LLVM+Clang with `LLVM_EXTERNAL_PROJECTS=iwyu` and `LLVM_EXTERNAL_IWYU_SOURCE_DIR`
> * with `CMAKE_PREFIX_PATH` pointing to a package-installed LLVM+Clang
> * with `CMAKE_PREFIX_PATH` pointing to an LLVM+Clang build tree
With the function above the first two use cases should work fine if you just point at the clang installation.
For the third case... Posting at where you grab clang from will work, but you can't install from that configuration. That's probably fine for development workflows but won't work if you're using it in your package distribution workflows. I'm not sure we should support that build configuration generally anyways. We have supported it because the Swift build system does unholy and awful things, but it's all a pile of hacks and it has lots of edge cases where it breaks.
https://github.com/llvm/llvm-project/pull/97197
More information about the cfe-commits
mailing list