From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=68.232.149.218; helo=esa8.dell-outbound.iphmx.com; envelope-from=karunakarpoosapalli@dell.com; receiver=edk2-devel@lists.01.org Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 CD2A1211B63DF for ; Wed, 9 Jan 2019 22:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1547100222; x=1578636222; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PxS8u8x/3AEHDQRW2wIOwPctXH/NbgJ81D/pENxkpT0=; b=TUPQPfNec/3iK6tBTUuugtrvPkFo1WlnBgU4vpsxoBBujwBT85EChhiP jon1BJjr9AFhfsEhZsl2wPkAJO6IVgl9RG2RgruuE+J9fr8zYkfKywPlB VmRx2WP26OxcmnVTZc5HHuHF4P76wQAiQ79l0qmacHHLX0BeEOEKWyDtX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAAAa3zZchyeV50NjGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgmmBAicKh0CEUF+LDYINl3cUgWcLAQE?= =?us-ascii?q?YCwkChD4CgiAiNAkNAQMBAQIBAQIBAQIQAQEBCgsJCCkjDII6IhyBCwEBAQE?= =?us-ascii?q?BAQEBASMqAg1jAQEBAQMBARAoNAsMBAIBCBEEAQEBHgkHJwEeCQgBAQQBEgg?= =?us-ascii?q?agwABggABD6ADPQKBbokGAQEBgh6DcjwBhg4FjD+CFoERgmQugx4BAgEBF4E?= =?us-ascii?q?TAQESAYVdIgKJQpgyCYcZhkCEHCCBZIUkinGJbYULiAuDLwIEAgQFAhSBRns?= =?us-ascii?q?jcXBQDRCCT4InDgmIX4U/QTEBgSeGaoEfAYEeAQE?= X-IPAS-Result: =?us-ascii?q?A2EBAAAa3zZchyeV50NjGQEBAQEBAQEBAQEBAQcBAQEBA?= =?us-ascii?q?QGBUQQBAQEBAQsBgmmBAicKh0CEUF+LDYINl3cUgWcLAQEYCwkChD4CgiAiN?= =?us-ascii?q?AkNAQMBAQIBAQIBAQIQAQEBCgsJCCkjDII6IhyBCwEBAQEBAQEBASMqAg1jA?= =?us-ascii?q?QEBAQMBARAoNAsMBAIBCBEEAQEBHgkHJwEeCQgBAQQBEggagwABggABD6ADP?= =?us-ascii?q?QKBbokGAQEBgh6DcjwBhg4FjD+CFoERgmQugx4BAgEBF4ETAQESAYVdIgKJQ?= =?us-ascii?q?pgyCYcZhkCEHCCBZIUkinGJbYULiAuDLwIEAgQFAhSBRnsjcXBQDRCCT4InD?= =?us-ascii?q?gmIX4U/QTEBgSeGaoEfAYEeAQE?= Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 10 Jan 2019 00:03:40 -0600 Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0A5wxaq014154 for ; Thu, 10 Jan 2019 01:03:40 -0500 Received: from esa1.dell-outbound2.iphmx.com (esa1.dell-outbound2.iphmx.com [68.232.153.201]) by mx0a-00154901.pphosted.com with ESMTP id 2pwsag1unx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 10 Jan 2019 01:03:40 -0500 From: Cc: , Received: from ausxippc106.us.dell.com ([143.166.85.156]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 10 Jan 2019 12:03:40 +0600 X-LoopCount0: from 10.166.132.23 X-IronPort-AV: E=Sophos;i="5.56,460,1539666000"; d="scan'208";a="338289057" To: , , Thread-Topic: [edk2] Conditional Compilation support in INF file Thread-Index: AdSn6DwaFQapYNOqQoKF9n2RWq0Njf//6EQAgAAcnoD//oKZUA== Date: Thu, 10 Jan 2019 06:03:34 +0000 Message-ID: <3cd149b2ee7942dda2ebef04bd0f6977@BLRX13MDC432.AMER.DELL.COM> References: <1a62f519f4b2466fb97c0dd7a81057e6@BLRX13MDC432.AMER.DELL.COM> <03c8ee0d-dca5-a7ca-b941-f45bd0fd6c38@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E3AE69B@SHSMSX152.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3AE69B@SHSMSX152.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [163.244.186.30] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100049 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: Thu, 10 Jan 2019 06:03:43 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I agree with providing the support like "FixedAtBuild PCD in INF". And we n= eed to modify or provide support in BaseTools to support this feature. There are more use cases or flexibility to developer if we support Conditio= nal compilation support in INF. As we're providing support in BaseTools for FixedAtBuild PCD support in INF= , Is there any challenges or drawbacks in providing conditional compilatio= n support in INF? =20 Thanks & Regards, Karunakar -----Original Message----- From: Gao, Liming [mailto:liming.gao@intel.com]=20 Sent: Wednesday, January 9, 2019 6:12 PM To: Laszlo Ersek; Poosapalli, Karunakar; edk2-devel@lists.01.org Subject: RE: [edk2] Conditional Compilation support in INF file [EXTERNAL EMAIL]=20 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=20 > Laszlo 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=20 > > 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=20 > following tools at our disposal, to customize module builds at the INF=20 > file level: >=20 > (1) Please see . > (Unfortunately, the INF file spec doesn't seem to document the syntax;=20 > > should help however.) >=20 > (2) If the number of cases that need to be distinguished is low, it's=20 > possible to duplicate the INF file, keep the [Sources] section(s) and=20 > similar sections identical, and only customize the sections that need=20 > changes. Then include the right INF file in the platform DSC and FDF=20 > files, dependent on PCD settings or build defines (macros). >=20 > (3) Sometimes it makes sense to delay the dispatching of a module=20 > until another module makes a decision about a platform feature, dynamical= ly. > An important characteristic of this case is that the dependent module=20 > should not be prevented from starting *completely* in case the=20 > platform feature is absent; it should only be made wait until the=20 > decision is recorded, by the other module. This way the dependent=20 > module will not incorrectly customize its own behavior before the=20 > 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=20 > *synthetic* protocol GUID -- installed in the protocol database with a=20 > NULL interface -- through which the decision-making module would=20 > simply advertize, "none of the relevant features are available, and=20 > you need not wait any longer". >=20 > "gThisParticularFeatureDisabledProtocolGuid" is usually defined /=20 > declared as a platform Pkg-specific GUID, in the appropriate DEC file,=20 > 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=20 > empty constructor function, and (b) the DEPEX of your choosing (see=20 > above). The library should do nothing else. Then, in the package DSC=20 > file, hook the library into the core module in question via NULL class=20 > resolution. As a result, the library will not alter the behavior of=20 > the core module, but the core module will inherit the depex (it will=20 > be AND-ed together with other dependencies that the core module might hav= e). >=20 > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel