How to cover a "corner case": the need for expressing dependencies on features

[mdortel-stm]

STMicroelectronics is willing to deliver its HAL drivers with a CMSIS Pack descriptor, the PDSC.
To address relationship between drivers, the definitions of conditions is naturally meant to be used.
Above drivers, we will deliver simple configurable examples, designed to cover all hardware families.
The relationship between example and used drivers should have been logically based on dependency, furthermore on dependency on APIs.
But, a strong structural constraints prevents from using that mechanism : HAL drivers will be delivered in a way where there will be on pack for each device family containing all peripheral drivers. In addition, there will not be a pack declaring a common API implemented in each family pack.
The consequence of this is that, for example, we need to find another mechanism to express dependency on drivers avoiding to list explicitly each driver component in each family pack, which would be a not acceptable maintenance effort.
In parallel, following the idea that component identification should be separated from component classification (meaning that both information must not be supported by the same element of the PDSC), a proposal arose : associate definitions of "features" in a component, allowing the classification of it, without the structural restriction of "only 1 value for 1 type of feature for 1 component".
So, our first idea was to propose to allow conditions on those features.
Understanding that this could be seen a proposal "pushing in the opposite way of CMSIS mindset", which states that dependencies between components should rely on identification, on the component itself or its API, an other way to address this (maybe ST-only) corner case could be to allow in the definition of the PDSC some entry points for proprietary extensions. As an example, @jkrech already pointed out to /package/devices/family/.../environment:

<environment name="microchip">
  <mchp:extension schemaVersion="1.0">
    <mchp:prerequisite component="MPLAB X IDE" version="[5.10-"/>
    <mchp:prerequisite component="MPLAB X IPE" version="[5.10-"/>
 </mchp:extension>
</environment>
…
<environment name="atmel">
   <at:extension schemaVersion="1.0">
       <at:atdf name="samc20/atdf/ATSAMC20G17A.atdf"/>
       <at:variant ordercode="SAMC20G17A-MU" vccmin="2.7" vccmax="5.5" tempmin="-40" tempmax="85"/>
…

[ReinhardKeil]

Can we discuss this next week in the Open-CMSIS-Pack meeting? Would you be able to present/share the problem to the wider audience?

[iomint]

I would prefer to postpone this discussion after the summer break of maxime (mdortel-stm) as he has been handling this discussion from the beginning starting in the Shadowfax context with Joachim and others.
Meantime, I attached here slides presented by ST in june in the shadowfax context giving some background
ShadowFax ST inputs Drivers Features_public.pdf