The .d is the default file name extension used by GCC for dependency files. Given the dependency files are in the build output and the makefiles reference them explicitly I'm not sure there is going to be lots of confusion. 

But I think it is likely the default dependency file name is mostly just a convenience in constructing the makefiles, since if you use a custom name each invocation has to do string operations to create a file with a custom extension. Given our makefiles are generated by a tool this is probably not really an issue for us. 

Does Visual Studio have the concept of a dependency file? If yes what suffix does that use, as I guess we could use that? I guess the dependency handling could just be some XML data in some larger Visual Studio meta data....

GCC/clang flags around dependencies. 

-MD

-MD is equivalent to -M -MF file, except that -E is not implied. The driver determines file based on whether an -o option is given. If it is, the driver uses its argument but with a suffix of .d, otherwise it takes the name of the input file, removes any directory components and suffix, and applies a .d suffix.

If -MD is used in conjunction with -E, any -o switch is understood to specify the dependency output file (see -MF), but if used without -E, each -o is understood to specify a target object file.

Since -E is not implied, -MD can be used to generate a dependency output file as a side effect of the compilation process



-MF file

When used with -M or -MM, specifies a file to write the dependencies to. If no -MF switch is given the preprocessor sends the rules to the same place it would send preprocessed output.

When used with the driver options -MD or -MMD, -MF overrides the default dependency output file.

If file is -, then the dependencies are written to stdout.


Thanks,

Andrew Fish

On Oct 28, 2019, at 8:03 AM, Yao, Jiewen <jiewen.yao@intel.com> wrote:

I think we need avoid confusing for future.
I don’t believe .d is good choice, since it is a known conflict.

Thank you
Yao Jiewen


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bob Feng
Sent: Monday, October 28, 2019 10:57 PM
To: Ryszard Knop <ryszard.knop@linux.intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate
source code dependency files.

Thanks for your comment. I think .d file should be fine since edk2 does not
support D language.

Thanks,
Bob

-----Original Message-----
From: Ryszard Knop <ryszard.knop@linux.intel.com>
Sent: Monday, October 28, 2019 8:24 PM
To: devel@edk2.groups.io; Feng, Bob C <bob.c.feng@intel.com>
Subject: Re: [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate
source code dependency files.

Just a quick note: .d files are used by the D language. You might want to use an
extension like .deps instead.

On 2019-10-28 11:47, Bob Feng wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311

To support incremental build, build tool generates the dependent
header file for each of source file. This procedure is done in AutoGen phase.
The build tool goes through all the source file and header file and
use regular expression to find out all the dependent files for a
source file. This procedure is much time-consuming. And this method
can't handle the MACRO in #include, for example #include PATH(xxx.h).

This patch is going to use compiler to generate dependent files. This
method will be faster and more accurate.

The basic idea is:
1. In AutoGen phase, build tool add "!Include deps.txt" into Makefile
instead of defining COMMON_DEPS list.
2. During the Make phase, the compilers, Trim and C preprocessor
generate dependent files, .d file, for each source file.
3. After Make, The build tool combines the .d files and generate a
file deps.txt which list all the included files for a module.
4. Each source file will depends on the Module's includes files. The
difference with orignial behavior is that if the user change the
source file, build tool will only build that source file in
incremental build; while if the user change a module's header file,
build tool will build the whole module in incremental build.

In this way, the time of AutoGen phase will be reduced much. And since
we will use c preprocessor to handle #include, the MACRO will be
handled well and the final dependent files will be more accurate.

Feng, Bob C (1):
  BaseTools: Using compiler to generate source code dependency files.

 BaseTools/Conf/build_rule.template            |  89 ++++++-----
 BaseTools/Conf/tools_def.template             | 138 +++++++++---------
 BaseTools/Source/Python/AutoGen/GenMake.py    |  73 +++------
 .../Source/Python/AutoGen/IncludesAutoGen.py  |  99 +++++++++++++
 BaseTools/Source/Python/Trim/Trim.py          | 113 +++++++++++---
 BaseTools/Source/Python/build/build.py        |  58 ++++++--
 6 files changed, 378 insertions(+), 192 deletions(-)
 create mode 100644
BaseTools/Source/Python/AutoGen/IncludesAutoGen.py