kousikk added a comment.
> I haven't looked into this in detail but it feels kind of wasteful to start a
> process just to get this value.
Right, that's why I cache this information. So multiple compile commands
sharing the same compiler process will trigger at 1 subprocess and then
subsequently use the cached information.
> Can't we just expose it in some of the clang libs we already link against?
The problem is, the value of `resource-dir` depends on `CLANG_VERSION` and
`ARCH` #define's, that's set when the clang binary is built. So lets say you
use `/home/kousikk/clang/7.0/bin/clang`, then if your compilation database is:
[
{ "command": "/home/kousikk/clang/7.0/bin/clang -c /home/kousikk/test.cpp",
"file": "/home/kousikk/test.cpp",
"directory": "/home/kousikk/"
}
]
then the value of `-resource-dir` for compilation of `test.cpp` must be
something like `/home/kousikk/clang/7.0/lib64/clang/7.0.0/`. Any libs used as
part of building `clang-scan-deps` itself is going to point to its own
resource-directory which is NOT the behaviour we want.
-------
> could we please add support for generic -extra-arg, which can then add
> -resource-dir like the other clang tools?
@arphaman would this be an option to `clang-scan-deps`? If so it might not work
since commands in the compilation-database can be using more than 1 version of
clang?
In addition, every project on which we use scan-deps will inturn have to
specify this extra argument - wouldn't it be better if they didn't have to do
that?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69122/new/
https://reviews.llvm.org/D69122
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
