From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 EA6F0211B5090 for ; Wed, 9 Jan 2019 03:00:05 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5D5C781F10; Wed, 9 Jan 2019 11:00:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-11.rdu2.redhat.com [10.10.120.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81F775D9CA; Wed, 9 Jan 2019 11:00:03 +0000 (UTC) To: KarunakarPoosapalli@Dell.com, edk2-devel@lists.01.org References: <1a62f519f4b2466fb97c0dd7a81057e6@BLRX13MDC432.AMER.DELL.COM> From: Laszlo Ersek Message-ID: <03c8ee0d-dca5-a7ca-b941-f45bd0fd6c38@redhat.com> Date: Wed, 9 Jan 2019 12:00:02 +0100 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: <1a62f519f4b2466fb97c0dd7a81057e6@BLRX13MDC432.AMER.DELL.COM> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 09 Jan 2019 11:00:04 +0000 (UTC) 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 11:00:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/09/19 07:55, KarunakarPoosapalli@Dell.com wrote: > Hi ALL, > > > > I've an idea regards "Adding conditional compilation support in INF files" > > > > 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 on it. 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: (1) Please see . (Unfortunately, the INF file spec doesn't seem to document the syntax; should help however.) (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). (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. In this case, it's usually possible to write the depex such as (gProtocolGuid1 AND gProtocolGuid2) OR (gProtocolGuid3 AND gProtocolGuid4) OR gThisParticularFeatureDisabledProtocolGuid 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". "gThisParticularFeatureDisabledProtocolGuid" is usually defined / declared as a platform Pkg-specific GUID, in the appropriate DEC file, and in Include/Guid/...., under the same Pkg. (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). Thanks Laszlo