From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mx.groups.io with SMTP id smtpd.web10.11904.1591184648962501109 for ; Wed, 03 Jun 2020 04:44:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=w8paUA/P; spf=pass (domain: nuviainc.com, ip: 209.85.221.66, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f66.google.com with SMTP id y17so1988031wrn.11 for ; Wed, 03 Jun 2020 04:44:08 -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=GQrRW5uhoR9zsmG5orLdqSOjMIjd20FnSsy3PYQdAB4=; b=w8paUA/PID12we0AchYyjko92O0C0mR21oW6Y6Pm9D3C32jsqP+CCrQ7aUfMFq3YkP fdcufMfCV36xFhViEUPG89O0yV5hF1/0e1X5PhP63WBqVNjBsz1Nuu2YyNX5SIbOJHeo +FP1OS1Op3E4ZXMA+pAb/GxW7LWHHjwfZ6c7M4qiorNC6q8rG9WXGA4cedjtpscSu+gV pBjOWk82uyLG5rtP3jq52cLC6gUESAkRUuPAQahQOFFNKdmqpk06RV2zZCMntn0ULHmx Neid6GuMCe9Ra3zhGNAyLX2Dzejb1g3Vzuw43Gwwi7W/6ZVGnn+BBJKURxQm8tzF8+Qo mJMA== 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=GQrRW5uhoR9zsmG5orLdqSOjMIjd20FnSsy3PYQdAB4=; b=KztFWid3eJSYeBe4n+Ss1mFIyT+iW4F2uXiAlEYUL0xftugzK186Ufwyz+GB7A1ste xVSecJDJ7DTt/q846EP++GEPwVFcvP7TU2MtamvSRb4xlUqRifYpzL2zjL04Z5ZjB82C /iXdx7Si7ubb8x0U6Tslj0Iq9SEPkhTjJIA1cVutrR1iD6De3RoinNkZPBhIWpdNyWuF iLN7ovij561nquq4x/Q5YC1O4hShwnCWyusAlXNtW81WWoJKcv0kaT+RGi2WHHUre5U1 TdmQZd+niu0tqZ0SuYed3EfNUtIYLhNHlY6l46+eY+XnKeMzJFgknv99hU74ouLyCXxF PHTQ== X-Gm-Message-State: AOAM530BQ6bQJ6GoQQQ7j3ksmPEoKEZTaqm9cyQ6Qy1WxQ3xCZkvhpqA oKsLZoN4SMbK55lUxfhplBwESYpBmKG2wXMBIcTeLmyd82FP7oXPDYVLq474RyLI77kFzE4hi34 qMy/vmMwdta578noHUqCSaT0LHIPp5yC5lr9yHX2q5CTCYfrtXUJp4w4kylvSasZwlg== X-Google-Smtp-Source: ABdhPJzaeAqNcwgjXCHzAoIQ36i59PQrlmbuqefzGayKM894EibyWjcHda0wT4iHKFEiJDljs4kJKg== X-Received: by 2002:adf:a350:: with SMTP id d16mr31634342wrb.237.1591184646916; Wed, 03 Jun 2020 04:44:06 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id w17sm3006345wra.71.2020.06.03.04.44.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 04:44:06 -0700 (PDT) Date: Wed, 3 Jun 2020 12:44:04 +0100 From: "Leif Lindholm" To: devel@edk2.groups.io, lersek@redhat.com Cc: michael.d.kinney@intel.com, Andrew Fish , Pankaj Bansal Subject: Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on package ordering Message-ID: <20200603114404.GQ28566@vanye> References: <20200529140251.23933-1-leif@nuviainc.com> <20200531224339.GA28566@vanye> <20200602142010.GL28566@vanye> 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 On Tue, Jun 02, 2020 at 18:20:26 +0200, Laszlo Ersek wrote: > On 06/02/20 16:20, Leif Lindholm wrote: > > On Tue, Jun 02, 2020 at 15:29:55 +0200, Laszlo Ersek wrote: > >> I have not been aware of the header name collision scenario (nor that > >> the [Packages] ordering was supposed to work around such issues). > > > > Nor had I... > > > >> 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. > >> """ > > > > Could I suggest striking: > > " -- 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"? > > I'm sad; that's the part I like the most! ;) That describes the actual > use case (I'm a fan of use case details in commit messages too). > > Anyway, I don't insist... > > > > > This document specifies a file format, not automatically edk2-related. > > I disagree with this specific statement; the INF spec says "edk2" in the > *name*. It's called "edk2 INF specification". > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications > > "This page contains the released versions of the EDK II Specifications > published using Gitbook." > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications#inf > > "This document describes the EDK II build information (INF) file format." > > The following link doesn't seem to load at the moment: > > https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/v/release/1.27/ > > but checking the source in the git repo > , the actual > text seems to say "EDK II Module Information (INF) File Specification". > > The whole feature is related to out-of-tree INF files (where header file > name collisions cannot be easily detected). My wording "edk2-related" was imprecise to the level of being incorrect, apologies for adding confusion. My intended point wast that here is nothing specific about colliding with headers in the edk2 repository. This aspect relates to *all* different repos used by a specific platform. (And given how much magic the EDK2 build system looks to a newcomer anyway...) > > I think we're reaching a point where a major documentation overhaul is > > necessary. I had already been reflecting on how the coding style > > document encompasses more than coding style (at one point it explains > > how while() loops are different from do{}while() loops). And we > > recently had that conversation around struct assignments which some > > maintainers claim are banned, but which is not mentioned in that > > document. > > > > Not trying to resolve that issue *now*, just reflecting on how some > > things have been added to these documents historically to deal with a > > specific issue, and ended up confusing things as improved development > > practices have made the original problem go away. > > > > So with the edk2 refences removed, I like your new wording. > > OK -- I won't let "perfect" get in the way of "good" :) So, umm, given that the entire actual content of the patch would now be written by you - could you submit possibly your own patch, and I'll abandon this one? I'd be happy with (or frankly, without :) a Suggested-by. Regards, Leif > Thanks! > Laszlo > > > >