Reasoning for clang-scan-deps tool

Hello Everyone. I will like to know the reasoning for a different tool clang-scan-deps to scan the dependencies instead of using the clang compiler itself.
In my case, I am the author of HMake build system. And want to support C++20 modules. For this, the requirement is compiler support for P1689R5. Integrating clang-scan-deps will be an extra twist. Is there a plan for including the support in the Clang compiler enabled with a compiler option?

https://reviews.llvm.org/D137527

clang-scan-depcs supports P1689R5. A cmake guy was in the review. It caches and is much faster than clang to figure out the dependendency graph.

Will clang-cl support the MSVC option /scanDependencies and other module-related options? Maybe Clang can integrate the clang-scan-deps tool in itself enabled with a compiler flag?

I am quite sure that it is used over the C-API in production. There is probably no MSVC support at the moment,

To maintain compatibility with cl.exe for supporting /scanDependencies, clang-cl.exe will need to integrate clang-scan-deps. clang.exe can also integrate clang-scan-deps. While clang-scan-deps can exist as a separate tool as well.

Hi,

for the motivation of clang-scan-deps, you can looks at https://www.youtube.com/watch?v=Ptr6e4CVTd4 and https://llvm.org/devmtg/2019-04/slides/TechTalk-Lorenz-clang-scan-deps_Fast_dependency_scanning_for_explicit_modules.pdf.

Is there a plan for including the support in the Clang compiler enabled with a compiler option?

We don’t have such plans.

To maintain compatibility with cl.exe for supporting /scanDependencies, clang-cl.exe will need to integrate clang-scan-deps.

Yes since the compatibility with cl.exe is a goal of clang too. But possibly we won’t do it recently.


Integrating clang-scan-deps will be an extra twist.

It may depends on the infrastructure of the tools. For example, cmake only takes five lines to adopt clang-scan-deps since its scanner is configurable.