[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

Thu Jan 5 05:34:50 PST 2023

ben.boeckel added a comment.

In D139168#4027637 <https://reviews.llvm.org/D139168#4027637>, @ChuanqiXu wrote:

> Currently, clang-scan-deps won't check for this. If we have multiple command lines with different `-MF` value, the make-style dependency information will be written to these different depfiles.

IMO, this is not suitable; there must be *one* depfile for Ninja to work (otherwise build tools will need to manually collate all of this into one for `ninja`.

> I feel like we have 2 (or 3) options
>
> 1. (The current way) Extract `-MF` in the command line of clang (from compilation database or from the args after `--`)

See above; it works for the file-by-file, but falls over with batch scanning.

> 2. (The original way) Specify `-MF` in the command line of clang-scan-deps.

I feel this scales and communicates what is happening much better because it actually is a flag for `clang-scan-deps` itself.

> 3. (Not good) Do nothing. I feel like it is possible for build systems to get the make-style dependency information by scanning twice. One for P1689 <https://reviews.llvm.org/P1689> format and one for make-format. It may be workable but it sounds a little bit silly.

In what mode will `clang` output `#include` information without erroring about missing `.pcm` files for `import` statements? `-E -fdirectives-only` perhaps? This further exacerbates the need for "fake" command lines and costs on platforms with expensive process execution.

> the make-style dependency information of input_file in <dep_file> will be overwritten. Or would cmake like to concat the results manually?

Every command gets its own unique `<dep_file>`. Scanning, compilation, etc. Overlapping is just asking for race conditions in the build.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139168/new/

https://reviews.llvm.org/D139168