From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=liming.gao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 056D82119FF5E for ; Wed, 9 Jan 2019 04:46:39 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2019 04:46:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,457,1539673200"; d="scan'208";a="290152532" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga005.jf.intel.com with ESMTP; 09 Jan 2019 04:46:37 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 9 Jan 2019 04:46:21 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 9 Jan 2019 04:46:20 -0800 Received: from shsmsx152.ccr.corp.intel.com ([169.254.6.44]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.196]) with mapi id 14.03.0415.000; Wed, 9 Jan 2019 20:42:29 +0800 From: "Gao, Liming" To: Laszlo Ersek , "KarunakarPoosapalli@Dell.com" , "edk2-devel@lists.01.org" Thread-Topic: [edk2] Conditional Compilation support in INF file Thread-Index: AdSn6DwaFQapYNOqQoKF9n2RWq0Njf//vlsA//9eEjA= Date: Wed, 9 Jan 2019 12:42:27 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3AE69B@SHSMSX152.ccr.corp.intel.com> References: <1a62f519f4b2466fb97c0dd7a81057e6@BLRX13MDC432.AMER.DELL.COM> <03c8ee0d-dca5-a7ca-b941-f45bd0fd6c38@redhat.com> In-Reply-To: <03c8ee0d-dca5-a7ca-b941-f45bd0fd6c38@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTRmYTQ5ZGUtZDBmMi00NjUxLWFjMzMtOWIzYTA4MDNhNWY0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ1wvRzV6ZjJiXC9veGVPMGk5U21WUStNSUY1KzdLS2RFWFRFOExleENWSXJmSlpaQlpVWWhxZWhINEt1VEpQS0t4In0= dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: Conditional Compilation support in INF file X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 12:46:40 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo: INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been ad= ded into INF spec git book (git@github.com:tianocore-docs/edk2-InfSpecifica= tion.git). BZ https://bugzilla.tianocore.org/show_bug.cgi?id=3D444 The change is in INF spec trunk. New version INF spec will include it.=20 Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of La= szlo Ersek > Sent: Wednesday, January 9, 2019 7:00 PM > To: KarunakarPoosapalli@Dell.com; edk2-devel@lists.01.org > Subject: Re: [edk2] Conditional Compilation support in INF file >=20 > On 01/09/19 07:55, KarunakarPoosapalli@Dell.com wrote: > > Hi ALL, > > > > > > > > I've an idea regards "Adding conditional compilation support in INF fi= les" > > > > > > > > Ides is like, we can condition check in INF file like below > > > > > > > > #if Condition1 > > > > Protocol1 > > > > #elif Condition2 > > > > Protocol2 > > > > #else > > > > Protocol3 > > > > #endif > > > > > > > > If we've this support we can add different protocols in DEPEX section, = Like we can put condition check and add rotococol1 for > Notebook and Protocol2 for Desktop. > > > > And will have so many benefits adding this support. > > > > > > > > I don't think current EDK2 support this. > > > > Please let me know comments/suggestions, so that I will start working o= n it. >=20 > I'm not sure this feature is really required. We already have the > following tools at our disposal, to customize module builds at the INF > file level: >=20 > (1) Please see . > (Unfortunately, the INF file spec doesn't seem to document the syntax; > > should help however.) >=20 > (2) If the number of cases that need to be distinguished is low, it's > possible to duplicate the INF file, keep the [Sources] section(s) and > similar sections identical, and only customize the sections that need > changes. Then include the right INF file in the platform DSC and FDF > files, dependent on PCD settings or build defines (macros). >=20 > (3) Sometimes it makes sense to delay the dispatching of a module until > another module makes a decision about a platform feature, dynamically. > An important characteristic of this case is that the dependent module > should not be prevented from starting *completely* in case the platform > feature is absent; it should only be made wait until the decision is > recorded, by the other module. This way the dependent module will not > incorrectly customize its own behavior before the decision on the > platform feature is made. >=20 > In this case, it's usually possible to write the depex such as >=20 > (gProtocolGuid1 AND gProtocolGuid2) OR > (gProtocolGuid3 AND gProtocolGuid4) OR > gThisParticularFeatureDisabledProtocolGuid >=20 > Here: > - gProtocolGuid1 and gProtocolGuid2 could be specific to "Notebook", > - gProtocolGuid3 and gProtocolGuid4 could be specific to "Desktop", > - and gThisParticularFeatureDisabledProtocolGuid would be a *synthetic* > protocol GUID -- installed in the protocol database with a NULL > interface -- through which the decision-making module would simply > advertize, "none of the relevant features are available, and you need > not wait any longer". >=20 > "gThisParticularFeatureDisabledProtocolGuid" is usually defined / > declared as a platform Pkg-specific GUID, in the appropriate DEC file, > and in Include/Guid/...., under the same Pkg. >=20 > (4) It is possible to hook such dependencies into other (core) modules. > In the platform Package, you can implement a library that (a) has an > empty constructor function, and (b) the DEPEX of your choosing (see > above). The library should do nothing else. Then, in the package DSC > file, hook the library into the core module in question via NULL class > resolution. As a result, the library will not alter the behavior of the > core module, but the core module will inherit the depex (it will be > AND-ed together with other dependencies that the core module might have). >=20 > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel