[projmgr] [buildmgr] Opportunity to introduce toolchain-independent configuration using the most common generic configurations

[VGRSTM]

Discussion initiated if #120

#120 (comment)
#120 (comment)
#120 (comment)

Sounds good to me to get dedicated issue to comment / amend on.

Discussion is about following yml schema contributions: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/schemas/common.schema.json

"OptimizeType": {
"enum": [ "max", "size", "speed", "debug" ],
"description": "Generic optimize levels (max, size, speed, debug) for code generation."
},
"DebugType": {
"enum": [ "on", "off" ],
"description": "Generic control for the generation of debug information (on, off)."
},
"WarningsType": {
"enum": [ "no", "all", "Misra", "AC5-like" ],
"description": "Control warnings (no, all, Misra, AC5-like)."
},

[ReinhardKeil]

The is inline with proposal #315

[tarek-bochkati]

after the translation controls options addition (ie. optimize, debug, warnings),
I have started supporting them into projmgr and buildmgr
while doing that I had some notes which I need to share with you:

• WarningsType enum AC5-like is only valid for AC6 compiler,
  thus I suggest either to remove it from the standart or add a mention in the documentation saying it's for AC6 only
• OptimizeType
  • I can agree that debug means the lowed optimization possible + plus adding more debug info into the generate ELF file.
    thus I'm wondering if it is worth replacing it by none and we can use the debug options to add debug information

    # GCC use-case
    if optimize=none
        if debug=on
            use -Og
        else
            use -O0
        endif
    endif
    

  • max is not clear for me:
    • for AC6 it should be linked to LTO: but is it -Omin (minimal size) or -Omax (best performance)
    • what about AC5 does it implies using Cross-Module Optimization ?
      and the same question as for AC6, is it using -Ospace -O3 or -Otime -O3
    • IAR does not have equivalent for -Omax optimization,
      but it does have max performance aka -Ohs --no_size_constraints
    • so I can retain the question does this max optimization targets size or performance ?
  • current enumeration values are debug, size, speed and max
    Comparing these values against to possible compilers optimization options,
    I'm wondering if it is worth adding low, medium and high values mirroring respectively -O1, -O2 and -O3
• options precedence: options could come from csolution/cproject and also from build-type/target-type
  • while implementing [projmgr,cbuildgen] support options (optimize, debug, warnings) #328 I avoided to do silent override of options, but the options merger should be discussed and implemented.

[brondani]

I would like to propose another control: the language standard for compilation.

LanguageC:
- c90
- gnu90
- c99
- gnu99
- c11
- gnu11

LanguageCPP:
- c++98
- gnu++98
- c++03
- gnu++03
- c++11
- gnu++11
- c++14
- gnu++14
- c++17
- gnu++17

[VGRSTM]

@brondani
On one hand +1 on the other such just demonstrate we are going to end up with a gas plant according to me ... I may myself contribute to many more compilation control requirements thinking to support all end user / toolchains requirements.

If limited to #179 (comment) proposal already only here I would add:

LanguageC:

• gnu18
• c18

LanguageCPP:

• gnu++20
• c++20

[VGRSTM]

Despite mixed feeling about myself because pro & cons I would promote possibly another way to progress here. Feel free to consider or not ... just a proposal trying to unlock this issue.

First let's come back to pro & cons to my point of view per my understanding:

• Pro: would be nice to get if basic / common projects some compiler agnostic project (*.yml) files. Such helps portability from one vendor to another
• Cons: end user is not exposed explicitly to toolchain setups ... stuff is working Thanks some kind of back magic (i.e. toolchain .cmake config files) he cannot act on. Not sure too how we can prevent clashes between yml based explicit end user setups & black magic addons ...

Such said my thinking would be rather to fight finding some commonalities across various toolchains, let's push black magic concept then. Instead promoting OptimizeType, DebugType, WarningType, LanguageType, .... let's promote only ProfileType.

"ProfileType": {
"enum": [ "debug", "release", "debug_verbose", "release_targetSpeed", "release_targetSize" ],
"description": "Generic target profiles abstracting various toolchain common setups"
},

[ReinhardKeil]

I believe this is implemented now

[ReinhardKeil]

no further feedback - hence I'm closing it as it is covered in the tools. Raise specific issues on perhaps missing features.