public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Andrew Fish" <afish@apple.com>
To: devel@edk2.groups.io, "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "Feng, Bob C" <bob.c.feng@intel.com>,
	Ryszard Knop <ryszard.knop@linux.intel.com>
Subject: Re: [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate source code dependency files.
Date: Mon, 28 Oct 2019 10:18:46 -0700	[thread overview]
Message-ID: <F92ADD4C-BAAC-4025-B9A8-93061B914A87@apple.com> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F828017@shsmsx102.ccr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 5588 bytes --]

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 <https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#dashMF>), 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 <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto: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 <mailto:ryszard.knop@linux.intel.com>>; devel@edk2.groups.io <mailto: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
>>> 
>> 
>> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 14387 bytes --]

  parent reply	other threads:[~2019-10-28 17:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 10:47 [Patch 0/1] BaseTools: Using compiler to generate source code dependency files Bob Feng
2019-10-28 10:47 ` [Patch 1/1] BaseTools: Generate source file dependency in Make phase Bob Feng
2019-10-28 12:23 ` [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate source code dependency files Ryszard Knop
2019-10-28 14:56   ` Bob Feng
2019-10-28 15:03     ` Yao, Jiewen
2019-10-28 15:25       ` Bob Feng
2019-10-28 17:18       ` Andrew Fish [this message]
2019-10-29  1:11         ` Bob Feng
2019-10-29  4:11           ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F92ADD4C-BAAC-4025-B9A8-93061B914A87@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox