Hi All, I agree with providing the support like "FixedAtBuild PCD in INF". And we need to modify or provide support in BaseTools to support this feature.
There are more use cases or flexibility to developer if we support Conditional 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 compilation support in INF? Thanks & Regards, Karunakar -----Original Message----- From: Gao, Liming [mailto:liming....@intel.com] 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] 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
