Closed VGRSTM closed 1 year ago
The is inline with proposal #315
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 onlyOptimizeType
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:-Omin
(minimal size) or -Omax
(best performance)Cross-Module Optimization
?
and the same question as for AC6, is it using -Ospace -O3
or -Otime -O3
-Omax
optimization,
but it does have max performance aka -Ohs --no_size_constraints
max
optimization targets size or performance ?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
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
@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 https://github.com/Open-CMSIS-Pack/devtools/issues/179#issuecomment-1168696618 proposal already only here I would add:
LanguageC:
LanguageCPP:
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:
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" },
I believe this is implemented now
no further feedback - hence I'm closing it as it is covered in the tools. Raise specific issues on perhaps missing features.
Discussion initiated if https://github.com/Open-CMSIS-Pack/devtools/issues/120
https://github.com/Open-CMSIS-Pack/devtools/issues/120#issuecomment-1050612457 https://github.com/Open-CMSIS-Pack/devtools/issues/120#issuecomment-1050634268 https://github.com/Open-CMSIS-Pack/devtools/issues/120#issuecomment-1055457730
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