packchk : remove WARNING M379 ?

[jeromecoutant]

With our current pdsc file describing B-U585I-IOT02A board, we got a M379 warning:

*** WARNING M379: xxx/STMicroelectronics.board_resources_B-U585I-IOT02A.pdsc (Line 52)
No example(s) found for Board '[STMicroelectronics] B-U585I-IOT02A'.

We don't plan to provide an example list for each board pdsc.

So proposition is to remove this warning in packchk and in
https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/packChk.html

@fred-r

[LMESTM]

@jeromecoutant
To be precise, we wouldn't want to deliver the example IDE projects within this packs, maybe a list of supported examples, but not included in the pack, might be useful (to be discussed).

[JonatanAntoni]

Hi @jeromecoutant, @LMESTM, @fred-r,

I think this warning can be discussed. Board specifications are typically provided as part of Board Support Packages (BSPs). And a BSP is expected to ship at least one example per board to give the user some sort of starting point.

You can supress this warning if required but I'd leave it in the tool.

Cheers,
Jonatan

[LMESTM]

@JonatanAntoni how would we supress the warning ?
We may want to decouple the projects deliveries from the board description part. Providing a single example might actually be a disappointment to the user who wants to get access to the full list of examples that can run on this board. It could be better to provide pointers to available examples maybe rather than one actual project ? (Also for which IDE anyway should the project be delivered ? and which IDE version ?)

[jkrech]

If you run packchk -h it should tell:

 -x Mxxx              : Suppress Messages

If yo ask me the format in the future should be csolution.yml and not for a specific IDE.

[LMESTM]

@JonatanAntoni thanks for the command.
I still think this should be left optional to the provider of the BSP pack to deliver a project or not.
I guess that we can live with the -x option. @jeromecoutant ?

[thorstendb-ARM]

Does this option solve the ticket? Or do we need further discussion.

[jkrech]

I suggest to close this specific issue. Conceptually we may want to think about a separate execution mode, where packchk provides feedback about the 'quality' / 'completeness' / 'use of features' of a Pack to cleanly separate between validation and enhancements.