The name of AC6x.x.x.cmake file

[AlbertHuang-CPU]

The current name is AC6.6.16.2.cmake.
And there are M85 inside the file. However AC6.16 doesn't support M52, M85 yet. This makes confusion somehow.
Since AC6 will no longer have new revision, will it be better to use the latest/final version (6.24) to rename this file?

Relevant discussion:
https://github.com/Open-CMSIS-Pack/devtools/issues/1928

[jkrech]

Please note that the version in the *.cmake files specify the minimum version.
We only update the *.cmake for incompatible command lines.
In case a processor is specified that is not supported by a compiler version (yet), the error message is quite clear. It is not the aim of this tool to track which versions of compilers support which processors. It is the Compiler's documentation to tell which version supports which processor.

[AlbertHuang-CPU]

How to know "which versions of compilers support which processors"- This is not my point.
My question is that why the name of this file use "6.16" rather than 6.12, 6.13, 6.18, 6.22, 6.24, etc.
I'd like to understand if anything behind this before I can add support for new processors to this file. @JonatanAntoni

[JonatanAntoni]

My question is that why the name of this file use "6.16" rather than 6.12, 6.13, 6.18, 6.22, 6.24, etc.

As Joachim wrote the version of the file is used as the min version this file shall be used for. E.g., we could have AC6.6.16.2.cmake and AC6.6.24.0.cmake. For compiler versions >=6.16.2 and <6.24.0 we'd pick the first one, and for later compiler version >=6.24.0 we'd pick the latter one.

This approach was selected to allow support breaking changes. I.e., let's say compilers later than 6.24.0 would not accept command line arguments anymore that were used before. This should however not happen if following semver versioning.

In case of new features, we decided no not split off the config files. I.e., we just added newer features to 6.16.2 even if that min version would actually not support those. A user trying to compile e.g. for STAR-MC3 with an Arm Compiler version not yet supporting -mcpu=star-mc3 should receive a meaningful error message from the compiler. So we never saw the need of catching such errors already at cmake configure stage.

Does that make sense to you?

[AlbertHuang-CPU]

Thanks Jonatan. I understand a bit more but feel not yet clear why exactly 6.16.2 is selected.
Anyway, I will just respect and follow the rule. I think it's safe now.
BTW, confirmed by compiler team, AC 6 will not have newer version than 6.24. The ATfE supersedes it.

[JonatanAntoni]

ATfE ist just Clang and should be covered by https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/buildmgr/cbuildgen/config/CLANG.17.0.1.cmake

The min version selection is kind of arbitrary. But it actually should not matter much as this is not directly exposed to the user.

[AlbertHuang-CPU]

ATfE ist just Clang and should be covered by https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/buildmgr/cbuildgen/config/CLANG.17.0.1.cmake

Then, I should add STAR-MC3 in this file rather than AC6.6.16.2.cmake. Or add it to both files but in AC6.6.16.2.cmake there is just a placeholder while in CLANG17.0.1.cmake there is the STAR-MC3 with the compiler flags.
Is that correct?

[JonatanAntoni]

I'd recommend to add flags to all compiler configs that are relevant to you. I think there is no need of any placeholders to compilers not receiving STAR-MC3 support. In case a user selects a compiler which does not support STAR-MC3, it will receive the according error message.

@brondani may advise about min version checks for certain flag support. I.e., if we add the flags to CLANG.17.0.1.cmake but actually Clang 20 is required, any older version would still succeed configuration phase but fail during compile phase. An error message at config phase might be desirable.

[brondani]

if we add the flags to CLANG.17.0.1.cmake but actually Clang 20 is required

If Clang 20 is required it is not backward compatible and a CLANG.20.x.x.cmake file should be created to accommodate the new flags onwards, regardless of configuration or compile phase.

In the long run my plan is to step out from cmake files for this purpose as captured in Open-CMSIS-Pack/cbuild2cmake#123.