public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: Leif Lindholm <leif@nuviainc.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Andrew Fish <afish@apple.com>, Laszlo Ersek <lersek@redhat.com>,
	"Pankaj Bansal" <pankaj.bansal@oss.nxp.com>
Subject: Re: [PATCH edk2-InfSpecification] Drop statement on package ordering
Date: Sun, 31 May 2020 22:19:24 +0000	[thread overview]
Message-ID: <MN2PR11MB4461F9382B829A31A9FB4376D28D0@MN2PR11MB4461.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20200529140251.23933-1-leif@nuviainc.com>

Hi Leif,

The reason for this statement is not for performance.

It is if the same include file exists in the same path
in more than one package.  Defining this behavior makes
the build system deterministic.

There is use case where a platform package can provide
an include override of a common package and the platform
modules list the platform package before the common
package in the [Packages] section.

So deterministic build when there are include file 
name collisions and overrides are 2 reasons to keep
the currently defined behavior.

With this background, perhaps some clarification or
rewording of the spec is required?  Do you have suggestions?

Thanks,

Mike

  This is not a common use case,
but one that does apply is a platform module that wants
to use an override of a standard include file in a platform
package.

For the build system autogen stage, this statement 

Mike

> -----Original Message-----
> From: Leif Lindholm <leif@nuviainc.com>
> Sent: Friday, May 29, 2020 7:03 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
> Andrew Fish <afish@apple.com>; Laszlo Ersek
> <lersek@redhat.com>; Pankaj Bansal
> <pankaj.bansal@oss.nxp.com>
> Subject: [PATCH edk2-InfSpecification] Drop statement
> on package ordering
> 
> The description of [Packages] sections stated that
> "Packages must be listed in the order that may be
> required for specifying
>  include path statements for a compiler. For example,
> the
>  MdePkg/MdePkg.dec file must be listed before the
>  MdeModulePkg/MdeModulePkg.dec file."
> 
> Drop it.
> 
> Signed-off-by: Leif Lindholm <leif@nuviainc.com>
> ---
> 
> Surely this isn't something we take seriously?
> If there is a measurable performance impact to the
> order of -I option
> on the compiler command line, we should approach this
> programmatically.
> 
>  3_edk_ii_inf_file_format/37_[packages]_sections.md | 7
> ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git
> a/3_edk_ii_inf_file_format/37_[packages]_sections.md
> b/3_edk_ii_inf_file_format/37_[packages]_sections.md
> index 17a8d91..c09112b 100644
> ---
> a/3_edk_ii_inf_file_format/37_[packages]_sections.md
> +++
> b/3_edk_ii_inf_file_format/37_[packages]_sections.md
> @@ -42,11 +42,8 @@ Defines the `[Packages]` section tag
> that is used in EDK II module INF files.
>  Each entry in this section contains a directory name,
> forward slash character
>  and the name of the DEC file contained in the
> directory name.
> 
> -Packages must be listed in the order that may be
> required for specifying
> -include path statements for a compiler. For example,
> the _MdePkg/MdePkg.dec_
> -file must be listed before the
> `MdeModulePkg/MdeModulePkg.dec` file. If there
> -are PCDs listed in the generated "As Built" INF, the
> packages that declare any
> -PCDs must be listed in this section.
> +If there are PCDs listed in the generated "As Built"
> INF, the packages that
> +declare any PCDs must be listed in this section.
> 
>  Each package filename must be listed only once per
> section. Package filenames
>  listed in architectural sections are not permitted to
> be listed in the common
> --
> 2.20.1


  reply	other threads:[~2020-05-31 22:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 14:02 [PATCH edk2-InfSpecification] Drop statement on package ordering Leif Lindholm
2020-05-31 22:19 ` Michael D Kinney [this message]
2020-05-31 22:43   ` [edk2-devel] " Leif Lindholm
2020-06-01  3:39     ` Pankaj Bansal
2020-06-01  5:15       ` Michael D Kinney
2020-06-01  7:01         ` Pankaj Bansal
2020-06-01 15:31           ` Michael D Kinney
2020-06-02 13:29     ` Laszlo Ersek
2020-06-02 13:37       ` Pankaj Bansal
2020-06-02 14:22         ` Leif Lindholm
2020-06-02 16:11         ` Laszlo Ersek
2020-06-03  3:12           ` Pankaj Bansal
2020-06-02 14:20       ` Leif Lindholm
2020-06-02 16:20         ` Laszlo Ersek
2020-06-03 11:44           ` Leif Lindholm
2020-06-03 13:43             ` Laszlo Ersek
2020-06-03  3:33 ` Andrew Fish
     [not found] ` <1614EB3F428C08F5.21938@groups.io>
2020-06-03  3:41   ` [edk2-devel] " 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=MN2PR11MB4461F9382B829A31A9FB4376D28D0@MN2PR11MB4461.namprd11.prod.outlook.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