Re: Conditional Compilation support in INF file

["Gao, Liming" <liming.gao@intel.com>]

Laszlo:
  INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been added into INF spec git book (git@github.com:tianocore-docs/edk2-InfSpecification.git). BZ https://bugzilla.tianocore.org/show_bug.cgi?id=444
  The change is in INF spec trunk. New version INF spec will include it. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 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
> 
> 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 <https://bugzilla.tianocore.org/show_bug.cgi?id=443>.
> (Unfortunately, the INF file spec doesn't seem to document the syntax;
> <https://lists.01.org/pipermail/edk2-devel/2017-March/008976.html>
> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel