public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Leif Lindholm <leif.lindholm@linaro.org>,
	"Gao, Liming" <liming.gao@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Wang, Jian J" <jian.j.wang@intel.com>,
	"Ye, Ting" <ting.ye@intel.com>
Subject: Re: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources]
Date: Thu, 25 Jul 2019 21:27:03 +0200	[thread overview]
Message-ID: <759d628c-fc79-a50b-6127-5de3467f8fda@redhat.com> (raw)
In-Reply-To: <20190724170050.GU11541@bivouac.eciton.net>

On 07/24/19 19:00, Leif Lindholm wrote:
> On Wed, Jul 24, 2019 at 03:17:56PM +0000, Gao, Liming wrote:
>>> Would it be feasible to update the --hash functionality to make use of
>>> the include dependencies extracted from the source files? (Clearly, we
>>> know when the source files change, so we would also know when we would
>>> need to re-run the dependency search.)
>>
>> The design is to save the step to extract the dependencies from the source files. 
>> I can further collect the build performance to be taken on the dependencies extraction
>> from the source files, and decide whether take this way. Another simple way is 
>> to calculate all source files in module directory and make sure there is no file missing for --hash option.
>>
>>>
>>> If not, I think we should make the explicit listing of .h files
>>> in .inf mandatory, triggering a build failure when not the case.
>>>
>>> If it is, then I think we should make it explicitly banned to list .h
>>> files in .inf. (If there is no other dependency, such as doxygen, also
>>> making use of .inf listings of .h files.)
>>
>> I know edk2 also has PI Packaging UPT. PI packaging requires all source 
>> files are listed in module INF file. Otherwise, some source files will be missed
>> in the packaging, and can't be rollback.
> 
> OK, this means we should update the documentation to be crystal clear
> that .h files need to be listed too.
> 
> I am OK to keep the warning enabled for now. But I would also wish
> that we start planning for making it an error at some point in the
> future.

Could you please file a Feature Request for that (i.e. s/warning/error/)
in the Bugzilla?

Thanks!
Laszlo

  reply	other threads:[~2019-07-25 19:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 16:43 [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources] Laszlo Ersek
2019-07-19 16:43 ` [PATCH 1/4] ArmPkg: list module-internal header files in INF [Sources] Laszlo Ersek
2019-07-19 16:43 ` [PATCH 2/4] ArmPlatformPkg: " Laszlo Ersek
2019-07-19 17:13   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-07-19 16:43 ` [PATCH 3/4] CryptoPkg/BaseCryptLib: " Laszlo Ersek
2019-07-19 17:09   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-07-22  5:48   ` Wang, Jian J
2019-07-19 16:43 ` [PATCH 4/4] EmbeddedPkg: " Laszlo Ersek
2019-07-19 17:08   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-07-22 10:37 ` [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources] Leif Lindholm
2019-07-22 17:32   ` Laszlo Ersek
2019-07-22 18:47     ` [edk2-devel] " Michael D Kinney
2019-07-22 22:56       ` Laszlo Ersek
2019-07-23  9:06         ` Leif Lindholm
2019-07-23 11:54           ` Laszlo Ersek
2019-07-23 12:19             ` Leif Lindholm
2019-07-23 13:02               ` Liming Gao
2019-07-23 13:25                 ` Leif Lindholm
2019-07-23 17:23                   ` Laszlo Ersek
2019-07-24 15:17                   ` Liming Gao
2019-07-24 17:00                     ` Leif Lindholm
2019-07-25 19:27                       ` Laszlo Ersek [this message]
2019-07-23 17:02               ` Laszlo Ersek
2019-07-22 22:30 ` Laszlo Ersek

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=759d628c-fc79-a50b-6127-5de3467f8fda@redhat.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