Clang tests are using "clang-scan-deps" from host system?

I was playing with modules in Clang.
And I noticed that when running Clang tests, they are using the
"clang-scan-deps" tool from my host system instead of from the build
dir.
For example, if I do:

bin/llvm-lit ../clang/test/ClangScanDeps/modules-pch.c -a

And look at the output commands, I see things like:

: 'RUN: at line 11';   clang-scan-deps -compilation-database
/Users/xun/OSS/llvm-project/build_clang/tools/clang/test/ClangScanDeps/Output/modules-pch.c.tmp/cdb.json
-format experimental-full    -generate-modules-path-args -module
-files-dir /Users/xun/OSS/llvm-project/build_clang/tools/clang/test/ClangScanDeps/Output/modules-pch.c.tmp/build
>> /Users/xun/OSS/llvm-project/build_clang/tools/clang/test/ClangScanDeps/Output/modules-pch.c.tmp/result_pch.json

where clang-scan-deps is not using an absolute path. I verified this
by adding "clang-scan-deps --version" in the test, and it matches my
system version, instead of the build version.

Is this a bug?

Sounds like a bug to me. There’s a list of tool replacements in the lit configs somewhere I think, that’s probably missing clang-scan-deps, I guess. (maybe we could make this mechanism more robust/less easy to skip/misuse)

Probably worth cc’ing/pulling someone into this thread who works on clang-scan-deps, folks don’t always keep up on all the mailing lists.

Sorry, to clarify, I double checked, it seems like in the test is it
somehow able to correctly associate the tool to the one from the build
dir, but just not printing out the absolute path.
So I guess it uses the search path in the environment variable when
running the test?
Still, I think we should be consistent on using absolute path (so that
it's easier to rerun the commands manually).

It sounds like something is passing around `clang-scan-deps` when it
should be `$<TARGET_FILE:clang-scan-deps>` in the CMake code (complete
guess, not having looked at the test declarations).

--Ben

Hi,

Thanks for pointing that out, you're right. I've created a patch that addresses this: https://reviews.llvm.org/D107155

Cheers,
Jan