Support for variables in flags

[jlonnberg]

Is there any support for using cmake-flags in the .cprj file?

The use case might be that one want's to generate a map file placed alongside the binary. This means adding
<ldflags add="--map=${OUT_DIR}/MyProject.map" compiler="IAR"/>
to the defintion. However, the usage of "$" is limited to variable expansion for parts of packs so the code generates a ACCSEQDELIM error.

[jlonnberg]

A possible solution would be to introduce an escape-sign for $, perhaps
$$
to copy ninja.
This allows for the usage of $ i commandlines as well

[jkrech]

Hi @jlonnberg, sorry for the late response.
Rather than looking at extending the cprj input format for cbuildgen we should focus on the csolution yml input format, because the longer term expectation is that we will remove cprj as an interim format.
Therefore it would be good to take a look at the handling of linker flags and the use of access sequences and see whether using an access sequence in a misc flag is actually supported and if not, how this functionality needs to be added.
A first experiment I did, seems to indicate that the access sequence is not correctly processed today (Version 1.5.0).

[jlonnberg]

@jkrech In which future is the .cprj expected to be replaced by the yml file? Will this mean that csolution is integrated into cbuildgen or vice versa, i.e., the workflow is expected to be yml->cmake rather than yml->cprj->cmake?

[VGRSTM]

@jkrech In which future is the .cprj expected to be replaced by the yml file? Will this mean that csolution is integrated into cbuildgen or vice versa, i.e., the workflow is expected to be yml->cmake rather than yml->cprj->cmake?

My understanding about future is yml -> yml -> cmake
More in details (csolution.yml + *.cproject.yml + *.clayer.yml) -> *.cbuild.yml -> *.cmake

[jkrech]

After reaching CMSIS-Toolbox 2.0 milestone, we plan to start eliminating the cprj format.

(csolution.yml + *.cproject.yml + *.clayer.yml) => (cbuild-idx.yml + *.cbuild.yml) => *.cmake

At that point we want to generate a hierarchy of cmake files which allow us to build configurations including:
a) inter-project dependencies
b) pre- and post-build steps

[jlonnberg]

Take this example for csolution.yml:

solution:
  build-types:
    - type: Debug
      compiler: IAR
    - type: Release
      compiler: IAR

  packs:
    - pack: ARM::CMSIS@5.9.0

  projects:
    - project: ./project.cproject.yml

  output-dirs:
    intdir: $OutDir(project)$/$TargetType$

  misc:
    - for-compiler: IAR
      Link:
        - --map=$OutDir(project)$/test.map

This tries to place a map file in the given output directory during the build. However, running csolution expands the $OutDir(...)$ variable. Secondly, the cbuildgen offers me to specify the output directory explicitly which I then would expect to override the previously supplied $OutDir(...)$.

[jkrech]

Instead of overriding the output directory with cbuildgen this will need to happen using csolution, since after csolution only cmake and e.g. ninja would be executed.

[jlonnberg]

I.e, remove the outdir option for cbuildgen?

[brondani]

In the sight of cprj deprecation also cbuildgen should be strongly simplified or even removed.

[brondani]

@jlonnberg The map file generation should now be covered in the cdefault.yml file that is shipped in the CMSIS-Toolbox 2.0.0-dev1, for example:

default:
   - for-compiler: IAR
     Link:
       - --map=$elf()$.map

Does it meet your expectations?
Please note as mentioned previously cbuildgen --outdir will be removed once the cprj handling replacement will be complete.

[jlonnberg]

@brondani Looks good to me! Will there be anyway for a user to access the output directories, e.g., dir of .o files and similar?

[brondani]

`> Will there be anyway for a user to access the output directories, e.g., dir of .o files and similar?

The output directory with build artifacts can be accessed with the OutDir() access sequence:
https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Input-Format.md#access-sequences
Object files (*.o) are seen as intermediate files rather than output files.

[jkrech]

Please raise a new issue in case you see a use case scenario where access to intermediate/tmp files (e.g. *.o) is needed.