From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (SPF Permanent Error: More than 10 MX records returned) identity=mailfrom; client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=liming.gao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7A3542216D8C6 for ; Thu, 14 Dec 2017 18:01:49 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 18:06:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,402,1508828400"; d="scan'208";a="12724032" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga004.fm.intel.com with ESMTP; 14 Dec 2017 18:06:30 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Dec 2017 18:06:30 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.213]) with mapi id 14.03.0319.002; Fri, 15 Dec 2017 10:06:28 +0800 From: "Gao, Liming" To: Leif Lindholm , "Ni, Ruiyu" CC: "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Dong, Eric" , "Zeng, Star" , Ard Biesheuvel Thread-Topic: [edk2] [PATCH 1/3] MdePkg: break #defines out of Uefi/UefiMultiPhase.h Thread-Index: AQHTdA2hf4FPMpaPTkyTTt/ZN6nnTqNBnJcAgACcbQCAAFK2AIABE/ig Date: Fri, 15 Dec 2017 02:06:27 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E192734@SHSMSX104.ccr.corp.intel.com> References: <20171213122630.17023-1-leif.lindholm@linaro.org> <20171213122630.17023-2-leif.lindholm@linaro.org> <59f1f807-a54c-9f4f-ce9f-aa83409dea8c@Intel.com> <20171214120356.gmlqyz5qrhue7ww6@bivouac.eciton.net> <20171214165958.q644lgoztzlg66jv@bivouac.eciton.net> In-Reply-To: <20171214165958.q644lgoztzlg66jv@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 1/3] MdePkg: break #defines out of Uefi/UefiMultiPhase.h X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 02:01:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leif: Right. Current VfrCompiler supports the limited C syntax. Many C syntax a= re not recognized. So, you will meet with the below build error.=20 For this change, I agree to share the definition between C and VFR source= files. The temp solution is to use #ifndef VFRCOMPILE around the definitio= n. The long term solution is to enhance VfrCompiler tool to recognize more = C syntax so that C and VFR can share more definitions. For long term soluti= on, you can submit feature request in bugzillia to catch it first. Thanks Liming > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Friday, December 15, 2017 1:00 AM > To: Ni, Ruiyu > Cc: edk2-devel@lists.01.org; Kinney, Michael D ; Dong, Eric ; Zeng, Star > ; Gao, Liming ; Ard Biesheuvel= > Subject: Re: [edk2] [PATCH 1/3] MdePkg: break #defines out of Uefi/UefiMu= ltiPhase.h >=20 > On Thu, Dec 14, 2017 at 12:03:56PM +0000, Leif Lindholm wrote: > > On Thu, Dec 14, 2017 at 10:44:04AM +0800, Ni, Ruiyu wrote: > > > Can we just move the definitions to UefiBaseTypes.h? > > > > There is nothing in UefiBaseTypes.h that is fundamentally easier to > > deal with than what is in UefiMultiPhase.h to begin with. > > > > > Even vfrcompiler still complains, the syntax enhancement to > > > vfrcompiler should be simple. > > > > It's (probably) not VfrCompile that would need to change. > > The problem is that the build runs the C preprocessor on the .vfr > > source files before passing them to VfrCompile. #defines that just > > replace text work fine, but typedefs and struct definitions make no > > sense in vfr source. > > > > It runs the preprocessor in C mode (for gpp, -x c) which means we > > cannot use __ASSEMBLER__ to filter out typedefs and struct > > definitions. > > > > We could perhaps switch to -x assembler-with-cpp (and filter > > UefiMultiPhase.h on __ASSEMBLER__), like we do for DTC. > > It _seems_ to work in my test, but I do not know what a corresponding > > change for VS would be. >=20 > Well, this turns out to be unworkable anyway, since the affected > .vfr source files depend on certain typedefs and struct definitions. > I was under the misconception that only #defines were used in .vfr. >=20 > So, yes, the better solution would be to teach VfrCompile to > understand enums and other things, but I wouldn't really know where to > start (and I'm about to disappear for a month). >=20 > Symptoms when building MdeModulePkg DriverSampleDxe with > UefiMultiPhase.h include >=20 > ERROR 12288: EFI_GUID > : undefined > ERROR 12288: enum > : unexpected token >=20 > If I then add UefiBaseTypes.h, we insted have issues from the > inclusion of ProcessorBind.h: >=20 > ERROR 12288: unsigned > : unexpected token > ERROR 12288: long > : unexpected token >=20 > and so on. >=20 > An alternative less invasive solution, which would avoid adding new > files, would be to add #ifndef VFRCOMPILE around everything other > than the EFI_VARIABLE_* #defines in UefiMultiPhase.h. >=20 > Would you be happier with that as a temporary measure until someone > gets around to looking at VfrCompile? >=20 > / > Leif