From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 23 Jul 2019 04:54:57 -0700 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D215B30842B5; Tue, 23 Jul 2019 11:54:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-52.ams2.redhat.com [10.36.117.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7CE9360497; Tue, 23 Jul 2019 11:54:55 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources] To: Leif Lindholm Cc: devel@edk2.groups.io, michael.d.kinney@intel.com, Ard Biesheuvel , "Wang, Jian J" , "Ye, Ting" References: <20190719164319.9070-1-lersek@redhat.com> <20190722103755.GA11541@bivouac.eciton.net> <591319a9-eceb-ab39-0ec0-ccd2530b0e58@redhat.com> <20190723090644.GD11541@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: Date: Tue, 23 Jul 2019 13:54:54 +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: <20190723090644.GD11541@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Tue, 23 Jul 2019 11:54:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/23/19 11:06, Leif Lindholm wrote: > On Tue, Jul 23, 2019 at 12:56:23AM +0200, Laszlo Ersek wrote: >> Hi Mike, >> >> On 07/22/19 20:47, Michael D Kinney wrote: >>> We could consider checking for these type of issues in >>> the ECC tool instead of build and make it an error from >>> ECC instead of a warning. >> >> I'm sorry, my reply to Leif was ambiguous (or worse). >> >> I meant that the issues underlying the specific warnings (emitted by the >> feature from TianoCore#1804) were annoying -- the reports were valid, >> and what "annoyed" me was that the INF files had not been in order (i.e. >> that they had missed some internal header files). > > Whereas I'm annoyed that we now have a manual process to match up with > the automatic dependency generation. > >> I wasn't annoyed at the feature itself -- if it helps developers catch >> unlisted headers as soon as incomplete INF files are introduced, then >> it's not a bad feature IMO. > > I agree that the optional nature of whether to list local .h files or > not in the .inf was suboptimal. Hmm, has that ever been officially optional? (The INF spec chapter at doesn't seem to mention header files at all. Thus, I can imagine both "mandatory to list headers" by omission, and "optional to list headers" by omission...) > I am just not pleased with the issue > bringing this to the fore is caused by the new caching feature using a > different mechanism for tracking header file dependencies than the > primary build process. Ugh... that's a lot of statements compressed into a single sentence. Can you please break it down for me? (Yes, I remember the mailing list reference you posted earlier, that discussion was too divergent for me.) Thanks Laszlo