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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
