From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web12.11723.1591107614785544595 for ; Tue, 02 Jun 2020 07:20:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=OzK4Xcd2; spf=pass (domain: nuviainc.com, ip: 209.85.128.68, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f68.google.com with SMTP id f185so3315697wmf.3 for ; Tue, 02 Jun 2020 07:20:14 -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=yvi2RIVUKQRFD7RHCFnbUyoWu8tPdY+I2mp08P4CKJU=; b=OzK4Xcd2+o03xlHSczVCtHywYJNr9hexlilfozFu2OoVC8a1Umf/Jht+pZt8+2gS6h MjRw+erCgBRMm/s91pbvzEefBaA33MnWikwOwYXnJ8S7qowRsK/lJVnJjzegvKfOzEDG x7o52LtJNj811LUOcpQqJAdbOx5NfHS5mQyITuwAMy7h6XktHdRDzKexn9kge9xoMKki o3nINReHy2vIxVY6qhSQ4EmEhGtBMRCtK1JnfpgRRdhQ9zpZkubyqYqKC72sL8VOhlS+ Bh5mbrVBL656SdxTxldjXP5rHL5Cp5Aii4CGZlI1UoiS42aaseRoZ0QOib8dUrvZKamJ jpJA== 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=yvi2RIVUKQRFD7RHCFnbUyoWu8tPdY+I2mp08P4CKJU=; b=gV7Gdd6zx8zo+e0UnqP6S3t+EFQjIdi5msOyJx3vewB77gTHxeY8LK/T30af1izkTx 9vG8tdQQTmKYEQLU5H3lDaEsQLkagUln2al7Z70T0RsjdIwpDhl9d+vKZlx6ucUht/hc dZZEX8N7CKRdkWYBkHO4M0OhCr89LO4hx/ZZnqPLhKRsu+ebliAMwARFphrQmC80tYXU sDj6CavohbvedDiHkIElg0b9RqkRbShC/lolFX8CgF9G01bcxcCYA7VUfG2u20E/KGBr x97sDNdvskTotinHA8Rf6X8voOF0vpXf216sunlwjO5p9beCNggufrnUuY2zs99mWrsr dLjA== X-Gm-Message-State: AOAM5315IwRWY5exHQ0ocZYGazWSjJRWiXRCnzDXKn/NZonhsXDpGN4k M4nt4TIyWrEA+Qyog39oYfANPw== X-Google-Smtp-Source: ABdhPJwO1ULs5sqe7MmHgIj2TlX3xvtPFFSJzBtF6VvTMEVOk1xX/y6BQJFp+cxxE0p5ey6og/Lf+g== X-Received: by 2002:a1c:4857:: with SMTP id v84mr4173497wma.96.1591107613330; Tue, 02 Jun 2020 07:20:13 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id x186sm4137642wmg.8.2020.06.02.07.20.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 07:20:12 -0700 (PDT) Date: Tue, 2 Jun 2020 15:20:10 +0100 From: "Leif Lindholm" To: Laszlo Ersek Cc: devel@edk2.groups.io, michael.d.kinney@intel.com, Andrew Fish , Pankaj Bansal Subject: Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on package ordering Message-ID: <20200602142010.GL28566@vanye> References: <20200529140251.23933-1-leif@nuviainc.com> <20200531224339.GA28566@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 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"? This document specifies a file format, not automatically edk2-related. 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. / Leif