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 firstname.lastname@example.org https://lists.01.org/mailman/listinfo/edk2-devel