Add gendirs: node to csolution.yml, cproject.yml, clayer.yml

[ReinhardKeil]

By default, the workingDir element of generators element specifies the output directory for generated files.

The workingDir is the location where the *.gpdsc file is generated. In this directory (or in sub-directories) generated artifacts are stored.

This specification in the PDSC file can be overwritten by an explicit gendirs: node in csolution.yml, cproject.yml, clayer.yml files.
The format of gendirs: is:

gendirs:
  - <generator-id>: <path>

Example:

gendirs:
  - Cube2: ./CubeFiles

If multiple gendirs for a <generator-id> exists, the tool generate an error.

The gendirs: specifies a relative path to the base directory of the csolution.yml, cproject.yml, or clayer.yml file (depending where it is applied). This allows to specify the location of generated files in the following scenarios:

For the csolution file, gendirs: could be specified under the target-type: which allows to make this directory depend on the target-type of the application.

For clayer.yml files, the location of the gendir: might be outside of the directory structure. This is an issue that is applicable to multi-processor or trustzone configurations of a clayer.yml. This is a ToDo and could be resolved by introducing a base-dir: in the clayer.yml file. This picture is an example of that configuation:

[slhultgren]

Hi @ReinhardKeil ,

I think it helps if we consider each item to be an object instead for the generator-dir in the cproject.yml.

E.g. something like this

generator-dir:
  - id: SomeSpecificGenerator
    path: ./MySpecificGenerator
  - id: *
    path: ./AllOtherGenerators/$GeneratorId$

• Identify the generators on a id property.
• Also support * as a catch-all wildcard to re-target all other generators
• Introduce a $GeneratorId$ access sequence to still allow separating output for each generator
• Drop the workingDir from the .pdsc entirely to simplify even further.
  • generator-dir should have a default value in the project if not specified
    • Proposed default value $CProjectYMLFolder$/generated/$GeneratorId$
• The generator-dir is also a type of output just like the rtedir, so it should be a child of the output-dirs, like the previous gendir
• On this item "If multiple gendirs for a <generator-id> exists, the tool generate an error.", If we are talking about multiple specifications within a single file, e.g. cproject.yml, then Yes.
  • All three yml files (csolution, cproject, clayer) should be able to specify the generator-dir simultaneously. The precedence rules should be
    • cproject.yml (most relevant)
    • csolution.yml (slightly less relevant)
    • clayer.yml (least relevant)

On the topic of shared code generation (e.g. the base-dir proposal), we don't think this is necessary.
Code generation can always be done independently from other projects. Certain options may be shared, but code is not.

[ReinhardKeil]

I like your proposed approach, except for:

• dropping workingDir. We need this for backward compatibility, but we may mark it as deprecated (stop using it).
• generator-dir is not really an output-dir from the perspective of the build step. Maybe we discuss that.

Let's evaluate base-dir: - I'm not a fan of it either and would like to drop it if possible.

I will work in your proposal into the specification and we take it from there. Please give me a few days.

[ReinhardKeil]

Specification changed in #876
PDSC specification clarified in Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#233
It is not a child of output-dirs: as output-dirs: is only possible in the *.csolution.yml file, whereas generator-dir: is applicable at multiple levels of the YML input.

[ReinhardKeil]

Replaced by #880 - suggest to continue discussion there

[slhultgren]

Specification changed in #876 PDSC specification clarified in Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#233 It is not a child of output-dirs: as output-dirs: is only possible in the *.csolution.yml file, whereas generator-dir: is applicable at multiple levels of the YML input.

@ReinhardKeil The schema still allows putting output-dirs in the cproject.yml files (even though it is not supported by tools yet), and I think this is required.

Having output-dirs in the csolution.yml/cdefault.yml files only I think is too restrictive.
This is probably going to force some pretty exotic access sequences over time to allow full flexibility on each cproject level to account for various cases.

For example, if we use the same cproject.yml in two different csolution.yml structures, there will be potentially completely different structures for the RTE/Generated/build files, so it seems this use-case is not really going to be well supported if we restrict output-dirs to only the csolution.yml files.

[ReinhardKeil]

I did review the out and tmp directory and I'm pretty sure that the right place to define the directory structure is in *.csolution.yml. Otherwise it gets too confusing.

But, let us review the .\RTE directory. Here I think you are correct. I will open a separate ticket on this.