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 10:02:15 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4607781F10; Tue, 23 Jul 2019 17:02:15 +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 DB297101E671; Tue, 23 Jul 2019 17:02:13 +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> <20190723121940.GH11541@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: Date: Tue, 23 Jul 2019 19:02:13 +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: <20190723121940.GH11541@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 23 Jul 2019 17:02:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/23/19 14:19, Leif Lindholm wrote: > On Tue, Jul 23, 2019 at 01:54:54PM +0200, Laszlo Ersek wrote: >>>> 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...) > > Yeah, indeed. > >>> 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.) > > The inclusion of .h files in .inf is not necessary for determining > build-time dependencies on the Makefile level. > > Thus, the warnings come out of a different and unrelated level of the > build system, related to the recent build cache features. Which means > we're checking header file build dependencies through two different > mechanisms at two different points of the build. OK, thanks. Now I understand your point. It hasn't been clear to me that listing the module-internal headers isn't actually necessary for getting the build dependencies right. > Or I have fundamentally misunderstood what is going on. Which is also > possible. In which case we're maintaining our own header file > dependency tracking infrastructure, despite us in the end relying on > generating Makefiles. Which also feels less than ideal. Right. Thanks Laszlo