Inappropriate order of build command line options defined by csolution/cproject.yml and cdefault.yml

[chentang16]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Build command line options, such as compiler, linker options can be defined in cdefault.yml or directly defined in csolution.yml or cproject.yml file. Now, if the same command line options, but different option values are defined in both cdefault.yml and csolution/cproject.yml, the command line options defined in cdefault.yml will be appended after the ones defined in csolution/cproject.yml, e.g. -gdwarf5 compiler options in my csolution.yml and -gdwarf4 in my cdefault.yml, as shown in the attached screenshot, -gdwarf4 from my cdefault.yml is appended after -gdwarf5 from my csolution.yml

If the same option is specified multiple times, for toolchains like Arm Compiler 6, Arm LLVM Clang or GNU the last occurrence of the option takes precedence. Thus, as the example above, -gdwarf5 defined in csolution.yml will not take effect.

Expected Behavior

I assume as a general project setup, cdefault.yml can be defined and used for a project as the "baseline" or "default" options that are fit for the most use case of the project. And individual option tweaks might be necessary for individual csolution/cproject setups that users want to define to "overwrite" the default options.
Thus, it is worth considering changing the order to make the command line options defined in csolution/cproject.yml be appended after the ones defined in cdefault.yml.

Steps To Reproduce

1. define -gdwarf4 in cdefault.yml
2. cdefault: is used in csolution.yml
3. define -gdwarf5 in csolution.yml
4. check the generated compile_commands.json

Affected tools

• cbridge
• cbuild
• cbuild2cmake
• cpackget
• csolution
• packchk
• svdconv
• vidx2pidx

Affected operating systems

• all
• Windows amd64
• Windows arm64
• Linux amd64
• Linux arm64
• MacOS amd64
• MacOS arm64

Environment

No response

[brondani]

According to the specification the misc are additive but nothing mandates their order, so it is implementation defined. This is in practice the order in the command line: cproject > csolution > cdefault > build-type > target-type

Generically I tend to agree with the suggested order, however cdefault is not active by default. It has to be enabled by adding cdefault to *.csolution.yml. It could be argued that with such inverted order enabling cdefault would have no effect.

[jkrech]

I think cdefault conceptually was added to cover typical, often compiler specific settings with the aim that this would set the basis.
Either the cdefault from ${CMSIS_TOOLBOX}/etc or a local copy is used. However the user can enable/disable the use from *.csolution.yml. Any further MISC settings should be able to refine and or override. Due to the additive nature, probably the ordering in the command line needs to be cdefault > csolution > target-type > build-type > cproject > clayer

[brondani]

@jkrech Can you please indicate also where in the order the misc under setup should appear?
Due to the potentially compatibility break should this reordering be planned for the next major release instead of the next minor?

[jkrech]

Please review:

cproject.setup > cproject.groups.group > cproject.groups.group.files.file
cproject.setup > cproject.component
cproject.setup > clayer

I agree, this is a breaking change. Let's ask for review feedback.