From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by mx.groups.io with SMTP id smtpd.web12.25180.1590965023643401707 for ; Sun, 31 May 2020 15:43:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=a1BhsOTD; spf=pass (domain: nuviainc.com, ip: 209.85.221.50, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f50.google.com with SMTP id r7so9693171wro.1 for ; Sun, 31 May 2020 15:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TlTiNc7Yo46BStRWwriTvJ2jM4+WIQz//XJLa7phK3A=; b=a1BhsOTDevD5WfdnzfWlEwqnZ3HmmJSQ/q4wWJ358pugOtiKzXSlYeH7peOt3nvPil bPjG3omltXnqkJoobejnh4E59zwub+eQ1uYarxlUXo9GRKMgdQX7WEnA7dU7ol2pjpSu qok7W//YutLV1hhujOug+YpFfqNGrHVIL7k30HhnsFuO1GjCD6kdfLJ1sMUagD/4Dr9x 0sqGO6Lb84uI+KfLYYBl0w4GIZhzW804+C5+8EBXYF9BWaGos+IrZ3eWkqQ0CCHHBfve VeCoh5RRu/qJdMDjiDZOKlXeUTNMqULK04G852lLCI6st365IcSy/cZ68bnEAVWCDkm/ c4Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TlTiNc7Yo46BStRWwriTvJ2jM4+WIQz//XJLa7phK3A=; b=aj/1AninbYeZ6wEQyq3FvVERXQ5NzymH2pbhAT3oS14b/mZgFzg344ENQsB7wzhWE6 E1/XqYblFJ1LiZJN8ftHiCgwibRvOaTd5mqT+yezYgHSgdat0GPGfWGWWaVxIJy46qG8 F5RroO+FC0sX+wleTHsT30VI4buzXLky9RlkB1LUY580xS1XWrfQFp98dnm7Smj1qIJk K+S7Pv1eRcxO2Ojq+iwGD/sZ8rd7n+je6PFP2pYIPORk1dv/ok4MokThiF2NgegPe8Jc DUy+nKUOwzFwd0X+rVPRsVxWKXZCSHr40PmP5wA+gSifu1XIVAA0AHmSu+elfkOS+s/f /cCw== X-Gm-Message-State: AOAM533pkW7+ISc7XB+0/jSPyfITeDT0bvDcYbJb/3n9p+7BChavCiow bY9E/vEmx08Awcxooi1FhVAP0Q7x382kA0u/AxI43SOeUqSOZCF1LiJx39+SM6qtPPd3ISDg7FD omiaM65b8HUvVFQU5HTMURYAwHR25lfRLIA8WYG8BjxLO1C58evCzbh2Jv1YKleEFAw== X-Google-Smtp-Source: ABdhPJys2l3cVZ5CdiBPaUnBujU0ypy/CYk2AbJjwk4KaIrvCyHWrtJ6WZWgWSkfHvLU3XkFbUBumQ== X-Received: by 2002:a5d:6444:: with SMTP id d4mr19762494wrw.239.1590965021901; Sun, 31 May 2020 15:43:41 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id l17sm8628968wmi.3.2020.05.31.15.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 May 2020 15:43:41 -0700 (PDT) Date: Sun, 31 May 2020 23:43:39 +0100 From: "Leif Lindholm" To: devel@edk2.groups.io, michael.d.kinney@intel.com Cc: Andrew Fish , Laszlo Ersek , Pankaj Bansal Subject: Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on package ordering Message-ID: <20200531224339.GA28566@vanye> References: <20200529140251.23933-1-leif@nuviainc.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Mike, Ok, I'm happy to hear that. I agree that the overriding behaviour is useful, and it would be good to document it. The problem is that the current wording does not say that (in a way that is useful to anyone who does not already know what it means). And the MdePkg/MdeModulePkg example sounds positively horrific when interpreted in this light. Clearly, my proposed modification is not the right thing to do here. The problem with the document implying that the order should reflect some sort of hierarchy *apart from when explicitly overriding* is that this is asking a human to do the thing that humans are bad at and computers are good at. It can't scale where humans are reviewing ports that they understand less well than the people contributing them. I think we should find a wording that explains the behaviour instead of explaining some potential derivative of the behaviour, as well as providing a realistic example instead of the MdePkg/MdeModulePkg statament. My suggestion is to keep it simple: say something like "where there is a need to override an include file provided by one package with one provided by another package, know that the compiler invocation will list the include directories in the same order as the .dec files are listed in the .inf". Regards, Leif On Sun, May 31, 2020 at 22:19:24 +0000, Michael D Kinney wrote: > 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 > > Sent: Friday, May 29, 2020 7:03 AM > > To: devel@edk2.groups.io > > Cc: Kinney, Michael D ; > > Andrew Fish ; Laszlo Ersek > > ; Pankaj Bansal > > > > 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 > > --- > > > > 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 > > > >