Laszlo: INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been added into INF spec git book (g...@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-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Wednesday, January 9, 2019 7:00 PM > To: karunakarpoosapa...@dell.com; edk2-devel@lists.01.org > Subject: Re: [edk2] Conditional Compilation support in INF file > > On 01/09/19 07:55, karunakarpoosapa...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
