From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.2063.1591114304970706077 for ; Tue, 02 Jun 2020 09:11:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HRXjpRmY; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591114304; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mAmjyyOTuyjFUro0pEzfvVJzs9HYNYAtxw8+Jku40HI=; b=HRXjpRmYKJHUNNSz7qZh3CKcgAFk2Q5tDNALLqLOIKcdht7zBUE6h3C1b7p5P/V3gBlPLh 5MplREg0thF18WHA/j8JJekAYwfF4AKenfx2ANLfNsOwTfHOzz4R44g765S5UHw7f0bQsR vmOrLl2cGMxxI37KIoGjsHb3UdkVEU0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-488-FK_3KQrePvS4jbCBjFsJ5g-1; Tue, 02 Jun 2020 12:11:40 -0400 X-MC-Unique: FK_3KQrePvS4jbCBjFsJ5g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C0FBAEC1A5; Tue, 2 Jun 2020 16:11:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-66.ams2.redhat.com [10.36.115.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id 50F475D9D3; Tue, 2 Jun 2020 16:11:37 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on package ordering To: "Pankaj Bansal (OSS)" , Leif Lindholm , "devel@edk2.groups.io" , "michael.d.kinney@intel.com" Cc: Andrew Fish References: <20200529140251.23933-1-leif@nuviainc.com> <20200531224339.GA28566@vanye> From: "Laszlo Ersek" Message-ID: Date: Tue, 2 Jun 2020 18:11:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/02/20 15:37, Pankaj Bansal (OSS) wrote: > > >> -----Original Message----- >> From: Laszlo Ersek >> Sent: Tuesday, June 2, 2020 7:00 PM >> To: Leif Lindholm ; devel@edk2.groups.io; >> michael.d.kinney@intel.com >> Cc: Andrew Fish ; Pankaj Bansal (OSS) >> >> Subject: Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on >> package ordering >> >> On 06/01/20 00:43, Leif Lindholm wrote: >>> 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". >> >> (since I've been copied) >> >> I have not been aware of the header name collision scenario (nor that >> the [Packages] ordering was supposed to work around such issues). >> >> I work strictly with edk2 proper, where a name collision like this can >> be detected, and so should be prevented. (Insert yet another argument >> why keeping platform code outside of edk2 is a bad idea.) In particular, >> a collision between MdePkg and MdeModulePkg would be super bad. >> >> Which now seems to turn out consistent with my general review point that >> the [Packages] section, like (almost) all other INF file sections, >> should be sorted lexicographically. >> >> How about replacing >> >> """ >> 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. >> """ >> >> with >> >> """ >> The order in which packages are listed may be relevant. Said order >> specifies in what order include path statements are generated for a >> compiler. Normally, header file name collisions are not expected between >> packages -- they are forbidden in edk2 proper --, but with a module INF >> consuming both edk2-native and out-of-edk2 packages, header file names >> may collide. For setting specific include path priorities, the packages >> may be listed in matching order in the INF file. Listing a package >> earlier will cause a compiler to consider include paths from that >> package earlier. >> """ > > Nicely summed up! it is much clearer now for anyone like me who wants to port edk2 for his platform. > one more suggestion. should this be mentioned along with above explaination: > "whenever possible use lexicographically ascending order" I'd love that, but it's really just a policy question that I prefer. If we tried to elevate my preference to official edk2 spec level, it could run into opposition (like any other proposal -- so that would be just fine, per se!). I just wouldn't like to delay the more important clarification with a discussion around my preference. So minimally, that would take a two-part patch series, and even so the second patch would likely have to be marked RFC. I think we can simply postpone the official speccing of the lexicographical sorting idea (indefinitely, even). Thanks Laszlo