From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: liming.gao@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by groups.io with SMTP; Tue, 23 Jul 2019 06:02:46 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 06:02:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,299,1559545200"; d="scan'208";a="344733162" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 23 Jul 2019 06:02:45 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Jul 2019 06:02:44 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Jul 2019 06:02:44 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.110]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.22]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 21:02:42 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "leif.lindholm@linaro.org" , Laszlo Ersek CC: "Kinney, Michael D" , Ard Biesheuvel , "Wang, Jian J" , "Ye, Ting" Subject: Re: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources] Thread-Topic: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources] Thread-Index: AQHVPlEXtkh4Y6imCEizBR/sM57SaqbV8EyAgABz7oCAABT+gIAARWeAgACqiACAAC78AIAABusAgACL/QA= Date: Tue, 23 Jul 2019 13:02:42 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4B11C4@SHSMSX104.ccr.corp.intel.com> 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> In-Reply-To: <20190723121940.GH11541@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzE4N2RjZDgtOWQyMC00OTM1LTgwYWEtMTc4Yjg4ZTYxMjU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRTVTM1h4OUpBWkFcLzJlcCtOZkVROWFKUFlvUnFjODVBZ2NlUmpETXR5Y1ErUTlWMElRdElQdHJVRHpzNkl6aDUifQ== dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leif: > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Le= if Lindholm > Sent: Tuesday, July 23, 2019 8:20 PM > To: Laszlo Ersek > Cc: devel@edk2.groups.io; Kinney, Michael D = ; Ard Biesheuvel ; Wang, Jian J > ; Ye, Ting > Subject: Re: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded= : list internal headers in [Sources] >=20 > 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 ca= tch > > >> unlisted headers as soon as incomplete INF files are introduced, th= en > > >> it's not a bad feature IMO. > > > > > > I agree that the optional nature of whether to list local .h files o= r > > > 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...) >=20 > Yeah, indeed. >=20 > > > 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. C= an > > you please break it down for me? (Yes, I remember the mailing list > > reference you posted earlier, that discussion was too divergent for me= .) >=20 > The inclusion of .h files in .inf is not necessary for determining > build-time dependencies on the Makefile level. Right. In fact, build tool will parse source file to find their dependent = header files,=20 and list those header files as the dependency in Makefile.=20 >=20 > 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. This is related to build feature --hash. When --hash option is enabled, bu= ild will calculate=20 the hash value of source files specified in INF file. If hash value is not= changed, build tool=20 will not parse source files, and not regenerate Makefile again. So, --hash= option=20 is the incremental way in the build parse phase. If some header files are = not=20 specified in INF file, it will cause hash value inaccurate. Then, Makefile= may not=20 be generated to match the real source code, and cause the incremental buil= d failure. So, the missing header files in INF file may bring the incremental build i= ssue when --hash option.=20 If you don't enable --hash option, there is no problem even if the missing= header files exist. Thanks Liming >=20 > 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. >=20 > / > Leif >=20 >=20