Dot character now disallowed in pack schema

[ckeydel]

After updating PackChk and gen-pack library to their latest versions (1.4.1 and 0.8.4, respectively) it is now raising errors for Cvariant identifiers that include the dot character, like

Cvariant="i.MX RT"

The error is

*** ERROR M511: XXXX.XXXXXXXXXX.pdsc (Line 162)
  Xerxes reports: value 'i.MX RT' does not match regular expression facet '[A-Za-z0-9\?\*][A-Za-z0-9_+()'/\-\s\?\*]*'

This was working fine before, why was this restriction added and any chance this can be reverted?

Cheers, Chris

[JonatanAntoni]

This restriction got introduced in 31b81e7 and made it into schema version 1.7.20.

[jkrech]

During the investigation of https://github.com/Open-CMSIS-Pack/devtools/issues/600 we had reviewed the usage of "special characters" in public package description files and were aiming for a minimal set of special characters for simplicity of typing component IDs in cproject.yml and clayer.yml files. We did not get any push back on this at the time of changing it. If we were to add the '.' to Cvariant, we would need to update the schema for YAML input files as well for the next full tool release.

Looking at your example, "i.MX RT", it sounds like a product series from NXP. Why is that needed in a Cvariant, since I would expect the component variant to be filtered by device already...

[ckeydel]

Looking at your example, "i.MX RT", it sounds like a product series from NXP. Why is that needed in a Cvariant, since I would expect the component variant to be filtered by device already

I shortened it for brevity, in reality it is, e.g. "i.MX RT/CAN2". The issue I am having is that I have different families which have different sets of CAN controllers. Only certain combinations are possible and they trigger the inclusion of different libraries so I have to clearly distinguish "i.MX RT/CAN2" from "LPC55/CAN2" for example so can't just simply call the Cvariant "CAN2".

[jkrech]

I don't pretend I understand your complete component structure, however I cannot see why and when both component variants would ever be available if one variant is for i.MX RT and the other for LPC55. That is the purpose of "conditions". Even though two components have the same componentID if they are only valid for different device series they are still "unique" for any project context, which always specifies the targeted device. In a well designed component architecture, you can switch the target device without the need to change any componentID.

[ckeydel]

It's not that simple because the Cvariants are also part of conditions. Believe me, I've tried, but it takes us away from the issue. I can't see why the dot should be disallowed. Just aiming for a minimal set of characters is not a good enough reason and I can see that other patterns allow the dot.

[ReinhardKeil]

@ckeydel we removed the dot in the syntax to allow future extensions. Keep in mind that we support command line tools such as CMSIS-Toolbox where components are specified.

While NXP uses i.MX RT on many places, the form iMXRT is also common. Could you consider renaming the cVariant in this way?

[ckeydel]

@ReinhardKeil I have used IMXRT now in order to make it build, this spelling you find at least in the names of NXP evaluation hardware like MIMXRT1170-EVK. Other than that, you won't find it spelled any different than i.MX RT in any official NXP source, perhaps some third parties have "misspelled' it as iMXRT. I actually don't mind much but when NXP complains about this I will refer them to you now. 😃