Re: Conditional Compilation support in INF file

[Laszlo Ersek <lersek@redhat.com>]

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