[csolution] Add `context-map` to csolution.yml to allow flexible reuse of cproject.yml by multiple csolution.yml files

[ReinhardKeil]

Resolution is captured here: YML-Input-Format - context-map

• A cproject.yml file defines the generation of a single binary image. This binary can be an executable or a library. • A csolution.yml file is a container describing an end user application and collects of one or more cproject.yml files. No functional code is defined in the csolution.yml itself, but this file contains the definition of build-types and target-types.

A cproject.yml is self-contained container an can be reused in several applications (i.e. several csolution.yml files could share the same boot loader or library project). However each cproject.yml needs to understand all build-types and target-types of the csolution.yml which limits the re-usability of the cproject.yml files.

Can we find a way to improve this situation?

Note: The problem needs to be consider holistically, with IDE operation in mind. Right now the VS Code IDE will offer in future direct selection of build-types and target-types of the csolution.yml that the user has selected. We should consider that.

Note: At cproject.yml level, there is just a type that combines right now both the build-type and the target-type. We might use this as another level of abstraction and introduce the term configuration type in future . Byte default build-type and target-type are directly assigned to this configuration type that is used in the cproject file, but we might add an assign method.

Potential Scenario (very similar to https://github.com/RobertRostohar/Demo_EW/tree/main/AWS_MQTT_MutualAuth_Demo):

A cproject.yml uses the following types:

• +TCP-IP to interface with a TCP-IP stack (which triggers inclusion of a clayer.yml)
• +Socket to interface with the IoT Socket (can then be mapped to WiFi, VSocket, or other).
• .Debug to compile in debug mode with additional test output
• .Release to compile in release mode with full optimization and no test output

A csolution.yml the target-type definitions might reflect different settings, but with an assign or alias setting we might overcome the issue described above, for example:

target-type: 
  - Production-Hw:            # uses TCP-IP stack
    board: iMXRT1062
    assign: +TCP-IP           # all projects will get +TCP-IP as type selection

  - AVH:                      # Arm Virtual Hardware, uses IoT-Socket
    board: AVH-Cortex-M7
    assign: +Socket           # all projects will get +TCP-IP as type selection

As the device/board selection is still used for translating the projects, the Pack conditions will work and the Access Sequences can be used to create for example different output directories for each project. It's just a different system.

A similar assign command could be added to the projects: list of a csolution.yml so that even at individual project level such controls could exist, for example:

projects:
    - project: ./blinky/Bootloader.cproject.yml
      assign-build-types:
         - Test: .Debug          # Build-type "Test" would map to configuration `type:` .Debug

[VGRSTM]

@ReinhardKeil I've feeling assign-build-types is working solution tackling https://github.com/Open-CMSIS-Pack/devtools/issues/355#issuecomment-1232510734. If my understanding is right such introduce capability to map some existing .cproject.yml content to a csolution.yml integration so I'm fine with.

[VGRSTM]

@ReinhardKeil coming back on such topic I'm sharing a thinking loud proposal just to stimulate.

Sounds we are in agreement about use case we have to support having cproject.yml as a self contain (except possible other cproject.yml dependencies if static lib for example) container we can reuse from onecsolution.yml` integration to another.

Looking at setups introduction, looking at "aliasing" proposal here .... I'm thinking maybe we can revisit all at once introducing build-types support as part of cproject.yml.

What do you think about 1) project1.cproject.yml

build-types: - type: Banana - type: Apple

2) project2.cproject.yml

build-types: - type: Orange

3) project.csolution.yml

build-types: - type: Exotic aliases: - Banana - Orange - type: Mix aliases: - Apple - Orange

In short:

• Add build-types to cproject.yml (get rid of setups so)
• Add "aliasing" to build-types

[tcsunhao]

I have a rethink about However each cproject.yml needs to understand all build-types and target-types of the csolution.yml which limits the re-usability of the cproject.yml files. :

1. The reason for sometimes cproject.yml must understand build-types and target-types is that some type specific contents(I think now is only source files including linkers, sorry in advance if I have made a mistake) can only be defined under cproject yml.
   In NXP, one real case is our RT platforms examples have many build-types. Each of some use dedicated linker file, under existing mechanism of cproject and csolution design, I could only record type specific linkers in the cproject.yml:

   - group: linker
     files:
       - file: ./MIMXRT1176xxxxx_cm7_flexspi_nor.scf
         for-type:
         - .flexspi_nor_debug
         - .flexspi_nor_release
         for-compiler: AC6
       - file: ./MIMXRT1176xxxxx_cm7_ram.scf
         for-type:
         - .debug
         - .release
         for-compiler: AC6
       - file: ./MIMXRT1176xxxxx_cm7_sdram.scf
         for-type:
         - .sdram_debug
         - .sdram_release
         for-compiler: AC6
       - file: ./MIMXRT1176xxxxx_cm7_ram.icf
         for-type:
         - .debug
         - .release
         for-compiler: IAR

   debug, release, sdram_debug, sdram_release, flexspi_nor_debug, flexspi_nor_release are defined in csolution, but nowhere in csolution for their linkers.

2. Just cproject needs to understand types from csolution actually doesn't always limit reusability: if cprojectX contains some types from solution A, then for new solution B, it can still directly use cprojectX, IDE/tool could just ignore the types and related contents/files from solution A inside cprojectX, and only use cprojectX common part to work with new solution B(a permissive way). The pre-condition is that in new solution B yml, any types specific contents/files can be directly defined without reediting cprojectX yml.

So it is the incapability of target/build type specific file/contents definition in csolution yml causes that target/build specific file can only be defined in cproject yml which causes csolution depends on cproject to work, not cproject depends on csolution to work, which means, for a new csolution, customers may probably anyway need to modify cproject to provide target/build type specific contents thus breaking the reusability of cproject.

Since csolution(not cproject) are designed for target/build types, then full specific target/build type contents of should be allowed to defined in csolution yml. Without this, we could never solve the reusablity of cproject.

I suggest to allow "groups" definitions Inside target-type and build-types somehow so that types specific files can be defined inside csolution(this is the only missing one). If "groups" are tool general, then we should identify which kinds files might be types specific and allow that definition in csolution.

For multiple projects sharing the same types of one solution. I think "assign-build-type" is necessary. To resolve the mapping between project types, like hello_world_cm7 flexspi_nor_debug works with hello_world_cm4 debug, hello_world_cm7 flexspi_nor_release works with hello_world_cm4 release. I propose following way in csolution.yml:

  projects:
    - project: ./cm4/hello_world_cm4.cproject.yml
      assign-build-types:
        - type: debug
        - type: release
    - project: ./cm7/hello_world_cm7.cproject.yml
      assign-build-types:
        - type: flexspi_nor_debug
          build_with: hello_world_cm4@debug
        - type: flexspi_nor_release
          build_with: hello_world_cm4@release

[tcsunhao]

I am not sure whether we could split this issue into 2 ones:

1. reusability of cproject
2. map for types to projects in csolution with multiple projects.

Of course point 2 may be part of point 1, but they are different level somehow, point 2 can be regarded as a feature.

Here we focus on point 2, in NXP real cases, in RT multiprocessor platform like RT1170, in multiprocessor projects, the working pair build-types of _cm4 and _cm7 are with different names: hello_world_cm7:

• flexspi_nor_debug
• flexspi_nor_release

hello_world_cm4:

• debug
• release

hello_world_cm7 flex_nor_debug works with hello_world_cm4 debug.

From readme.txt: The Multicore Hello World demo application demonstrates how to set up projects for individual cores on a multicore system. In this demo, the primary core prints the "Hello World from the Primary Core!" string to the terminal and then releases the secondary core from the reset. The secondary core toggles an on-board LED indicating that the secondary core is running. This naming is reasonable. Primary core boot from flexspi_nor flash, secondary core image is copied into ram to run. I don't see enough reasons to persuade example owners to modify target names. And apparently, they think Open-CMSIS-Pack should support such case because it is normal case.

In conclusion, we think maps between build-types and projects are critical information for multiple project solution.

[ReinhardKeil]

This proposal adds context-map: to target-types: and build-types: which solves two problems:

• Integrate cproject.yml files that use different target/build types as the main project (in this case Demo)
• Defines how projects are combined to a solution for the final target (needs reflection in cbuild-idx.yml).

Example:

  target-types:
    - type: IP-Stack
      context-map:
        - context: TFM.Release+LibMode   # for project TFM use build-type: Release, target-type: LibMode
        - context: Boot+Flash            # for project Boot use target-type: Flash
      device: MIMXRT1052DVL6B
    - type: WiFi
      context-map:
        - context: TFM.Release+LibMode   # for project TFM use build-type: Release, target-type: LibMode
        - context: Boot+Flash            # for project Boot use target-type: Flash
      board: B-U585I-IOT02A
      device: STM32U585AIIx
    - type: AVH
      context-map:
        - context: TFM.Release+LibMode   # for project TFM use build-type: Release, target-type: LibMode
      device: ARM::SSE-300-MPS3

  projects:
    - project: ./App/Demo.cproject.yml
    - project: ./Security/TFM.cproject.yml
    - project: ./Loader/Boot.cproject.yml

A context name is: [project-name][.build-type][+target-type]

• At csolution.yml level build/target-type is used.
• At cproject.yml level context name is used.

By default the build/target-types are mapped 1:1 to the context. With context-map: it is possible to re-assign this mapping for specific projects in the csolution.yml file.

Example:

 target-types:
    - type: DualCore
      device: MyDualCoreDevice

  build-types:
    - type: release
      context-map:
        - context: HelloCM7.flex_release     # project HelloCM7 uses build-type "flex_release" instead of "release"

  projects:
    - project: ./CM7/HelloCM7.cproject.yml
    - project: ./CM4/HelloCM4.cproject.yml

This mapping also indicates how projects are used in combination (when loaded to the target). For example, the Demo project would be always used with TFM.Release+LibMode regardless of the target-type/build-type setting.

Note: At cproject.yml level, the for-type: and not-for-type: should be renamed to for-context: and not-for-context:

In a IDE the selection might be shown like this:

To provide additional information, the cproject.yml format could be extended with context-info: as shown in the example below.

   context-info:
      - context: +IP-Stack
        description: Implements a TCP/IP communication stack at application level
      - context: +WiFi
        description: uses a WiFi device with integrated TCP/IP stack
      - context: +AVH
        description: uses a Arm Virtual Hardware with IoT Socket interface

Notes:

• IDE may generate context-info: based on for-context: and not-for-context: usage and csolution.yml information.
• When a context-info: does not contain information about target-types: or build-types: it is assumed that it works with any type.

[jkrech]

Mapping the above to the dual core example I believe this would be expressed like this:

  target-types:
    - type: DualCore
      device: MyDualCoreDevice

  build-types:
    - type: release
      context-map:
        - context: Hello_World_CM7.flexspi_nor_release+DualCore  # pname in cproject specifies the processor instance CM7

    - type: debug
      context-map:
        - context: Hello_World_CM7.flexspi_nor_debug+DualCore # pname in cproject specifies the processor instance CM4

  projects:
    - project: ./CM7/Hello_World_CM7.cproject.yml
    - project: ./CM4/Hello_World_CM4.cproject.yml

All contexts of a common build-type/target-type combination (e.g. .release+DualCore) are considered a set of dependent projects that contribute to the programming of the device

[ReinhardKeil]

@jkrech is correct, but since target-type (DualCore) is identical it might be even simplified to what is shown below. The result would be identical, but it allows to add more target-types, i.e. another slightly different device.

  target-types:
    - type: DualCore
      device: MyDualCoreDevice

  build-types:
    - type: release
      context-map:
        - context: Hello_World_CM7.flexspi_nor_release  # pname in cproject specifies the processor instance CM7

    - type: debug
      context-map:
        - context: Hello_World_CM7.flexspi_nor_debug # pname in cproject specifies the processor instance CM4

  projects:
    - project: ./CM7/Hello_World_CM7.cproject.yml
    - project: ./CM4/Hello_World_CM4.cproject.yml

[tcsunhao]

Hi @ReinhardKeil ，can I ask where does flexspi_nor_debug of Hello_World_CM7 define, in ./Hello_World_CM7.cproject.yml?

[ReinhardKeil]

@tcsunhao the problem statement was "each cproject must understand all built-types and target-types that are defined in a csolution". Maybe the example is therefore a bit confusing.

The assumption in the example below is:

• CM7.cproject.yml understands all 4 build-types and reacts different (based on for-type:), but
• CM4.cproject.yml understands just 2 build-types (.debug and .release).

This example would be:

target-types:
    - type: DualCore
      device: MyDualCoreDevice

  build-types:
    - type: release

    - type: flexspi_nor_release
      context-map:
        - context: Hello_World_CM4.release

    - type: debug

    - type: flexspi_nor_debug
      context-map:
        - context: Hello_World_CM4.debug

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

I believe this cannot be represented with the alias approach

[ReinhardKeil]

Hi @ReinhardKeil ，can I ask where does flexspi_nor_debug of Hello_World_CM7 define, in ./Hello_World_CM7.cproject.yml?

In your example you are using 'for-type:` to query the different build types. This is where they would be used.

[tcsunhao]

Hi @ReinhardKeil , thanks for this explain. I agree that alias cannot meet NXP hello_world cm4 or cm7 needs.

I have a question related to

CM7.cproject.yml understands all 4 build-types and reacts different (based on for-type:)

Honestly, I don't understand how is "based on for-type". The hello_world_cm7 should also just understand 2 build-types flexspi_nor_debug and flexspi_nor_release. In NXP case, hello_world_cm7 should always run with hello_world_cm4.

[ReinhardKeil]

Defining build-types or target-types typically implies that the cproject files query these types with for-type:.

CM7.cproject.yml understands all 4 build-types and reacts different (based on for-type:) This project uses for-type: to query all 4 build-types

CM4.cproject.yml understands just 2 build-types (.debug and .release). This project uses for-type: to query only .debug and .release build-types. For other build types it has no queries, hence the mapping via context-map

[tcsunhao]

(Sorry for this late reply) For hello_world_cm4/hello_world_cm7 projects/solution, Here can be a version csolution.yml

solution:
  target-types:
    - type: mdk
      compiler: AC6

  build-types:
    - type: debug
      defines:
        - DEBUG
      misc:
        - compiler: AC6
          C:
            - -O1
            - -g
          CPP:
            - -O1
            - -g

    - type: flexspi_nor_debug
      defines:
        - DEBUG
      misc:
        - compiler: AC6
          C:
            - -O1
            - -g
          CPP:
            - -O1
            - -g

    - type: release
      defines:
        - NDEBUG
      misc:
        - compiler: AC6
          C:
            - -Oz
          CPP:
            - -Oz

    - type: flexspi_nor_release
      defines:
        - NDEBUG
      misc:
        - compiler: AC6
          C:
            - -Oz
          CPP:
            - -Oz
  output-dirs:
    outdir: ./$Project$/$TargetType$/$BuildType$
    rtedir: ./RTE/$TargetType$

  projects:
    - project: ./cm4/hello_world_cm4.cproject.yml
    - project: ./cm7/hello_world_cm7.cproject.yml

hello_world_cm4.cproject.yml

---
# yaml-language-server: $schema=../../../../pack_xsd/cproject.schema.json
# TODO need to convert image to core1_image.bin
project:
  device: MIMXRT1176DVMAA:cm4
  components:
    - component: ARM::CMSIS:CORE
    - component: NXP::Device:Startup                        ###
    - component: NXP::Device:CMSIS:MIMXRT1176_header        # device.MIMXRT1176_CMSIS
    - component: NXP::Device:CMSIS:MIMXRT1176_system        ###
    - component: NXP::Board Support:SDK Drivers:evkmimxrt1170        # driver.xip_board.evkmimxrt1170
    - component: NXP::Device:SDK Drivers:clock              ###
    - component: NXP::Device:SDK Drivers:common             ###
    - component: NXP::Device:SDK Drivers:gpio              # driver.igpio
    - component: NXP::Device:SDK Drivers:lists              ###
    - component: NXP::Device:SDK Drivers:xip_device               ###
    - component: NXP::Device:SDK Drivers:iomuxc               ###
    - component: NXP::Device:SDK Drivers:pmu_1               ###
    - component: NXP::Device:SDK Drivers:mu              ###
    - component: NXP::Device:SDK Drivers:dcdc_soc               ###
    - component: NXP::Device:SDK Drivers:cache_lmem               ###
    - component: NXP::Device:SDK Drivers:anatop_ai               ###
    - component: NXP::Device:SDK Drivers:lpuart               ###
    - component: NXP::Device:SDK Drivers:lpuart_adapter       ###
    - component: NXP::Device:SDK Utilities:assert_lite        ###
    - component: NXP::Device:SDK Utilities:debug_console_lite ###

  groups:
    - group: source
      files:
        - file: ./hello_world_core1.c

    - group: mcmgr
      files:
        - file: ./mcmgr/src/mcmgr_internal_core_api_imxrt1170.c
        - file: ./mcmgr/src/mcmgr_mu_internal.c
        - file: ./mcmgr/src/mcmgr_internal_core_api.h
        - file: ./mcmgr/src/mcmgr.c
        - file: ./mcmgr/src/mcmgr.h

    - group: board
      files:
        - file: ./board.c
        - file: ./board.h
        - file: ./clock_config.c
        - file: ./clock_config.h
        - file: ./pin_mux.c
        - file: ./pin_mux.h

    - group: linker
      files:
        - file: ./MIMXRT1176xxxxx_cm4_ram.scf
          for-type:
          - .debug
          - .release
          for-compiler: AC6

    - group: doc
      files:
        - file: ./readme.txt

  setups:
    - setup: AC6
      for-compiler: AC6
      defines:
        # as-define
        - __STARTUP_CLEAR_BSS
        - __STARTUP_INITIALIZE_NONCACHEDATA
        # cc-define
        - CPU_MIMXRT1176DVMAA_cm4
        - FLEXSPI_IN_USE
        - MCMGR_HANDLE_EXCEPTIONS=1
        - __SEMIHOST_HARDFAULT_DISABLE=1
        - MULTICORE_APP=1
        - MCUXPRESSO_SDK
      misc:
        - ASM:
            - "-mcpu=cortex-m4"
            - "......."
          C:
            - "-mcpu=cortex-m4"
            - "......."
          CPP:
            - "-mcpu=cortex-m4"
            - "......."

          Link:
            - "--cpu Cortex-M4.fp"
            - "......."

hello_world_cm7.cproject.yml

---
# yaml-language-server: $schema=../../../../pack_xsd/cproject.schema.json

---
# yaml-language-server: $schema=../../../../pack_xsd/cproject.schema.json

project:
  device: MIMXRT1176DVMAA:cm7
  components:
    - component: ARM::CMSIS:CORE
    - component: NXP::Device:Startup                        ###
    - component: NXP::Device:CMSIS:MIMXRT1176_header        # device.MIMXRT1176_CMSIS
    - component: NXP::Device:CMSIS:MIMXRT1176_system        ###
    - component: NXP::Board Support:SDK Drivers:evkmimxrt1170        # driver.xip_board.evkmimxrt1170
    - component: NXP::Device:SDK Drivers:clock              ###
    - component: NXP::Device:SDK Drivers:common             ###
    - component: NXP::Device:SDK Drivers:gpio              # driver.igpio
    - component: NXP::Device:SDK Drivers:lists              ###
    - component: NXP::Device:SDK Drivers:xip_device               ###
    - component: NXP::Device:SDK Drivers:iomuxc               ###
    - component: NXP::Device:SDK Drivers:pmu_1               ###
    - component: NXP::Device:SDK Drivers:mu              ###
    - component: NXP::Device:SDK Drivers:dcdc_soc               ###
    - component: NXP::Device:SDK Drivers:anatop_ai               ###
    - component: NXP::Device:SDK Drivers:lpuart               ###
    - component: NXP::Device:SDK Drivers:lpuart_adapter       ###
    - component: NXP::Device:SDK Drivers:cache
    - component: NXP::Device:SDK Utilities:assert_lite        ###
    - component: NXP::Device:SDK Utilities:debug_console_lite ###
    - component: NXP::Device:SDK Utilities:incbin ###

  add-paths:
    - $OutDir(hello_world_cm4)$

  groups:
    - group: source
      files:
        - file: ./hello_world_core0.c

    - group: mcmgr
      files:
        - file: ./mcmgr/src/mcmgr_internal_core_api_imxrt1170.c
        - file: ./mcmgr/src/mcmgr_mu_internal.c
        - file: ./mcmgr/src/mcmgr_internal_core_api.h
        - file: ./mcmgr/src/mcmgr.c
        - file: ./mcmgr/src/mcmgr.h

    - group: board
      files:
        - file: ./board.c
        - file: ./board.h
        - file: ./clock_config.c
        - file: ./clock_config.h
        - file: ./pin_mux.c
        - file: ./pin_mux.h

    - group: linker
      files:
        - file: ./MIMXRT1176xxxxx_cm7_flexspi_nor.scf
          for-type:
          - .flexspi_nor_debug
          - .flexspi_nor_release
          for-compiler: AC6

    - group: doc
      files:
        - file: ./readme.txt

  setups:
    - setup: AC6
      for-compiler: AC6
      defines:
        # as-define
        - __STARTUP_CLEAR_BSS
        - __STARTUP_INITIALIZE_NONCACHEDATA
        # cc-define
        - CPU_MIMXRT1176DVMAA_cm4
        - FLEXSPI_IN_USE
        - MCMGR_HANDLE_EXCEPTIONS=1
        - __SEMIHOST_HARDFAULT_DISABLE=1
        - MULTICORE_APP=1
        - MCUXPRESSO_SDK
      misc:
        - C:
            - "-mcpu=cortex-m7"
            - "......"
          CPP:
            - "-mcpu=cortex-m7"
            - "......"

          Link:
            - "--keep=*(*core1_code)"
            - "......"

Hi @ReinhardKeil could you give a whole picture of your proposal by editting about 3 ymls? I have trouble fully understand your proposal. Thank you very much!

[ReinhardKeil]

@tcsunhao thanks for the example.

In your example, the CM4 project only builds with build-type ".Debug, .Release", whereas CM7 requires ".flexspi_nor_debug", ".flexspi_nor_release".

What we want to achieve is that for a single built-type/target-type configuration both projects are generated in a compatible way. So both projects should compile with ".Debug, .Release". But we also said, that existing .cproject files might be used across many projects and therefore should not be modified. Instead the mapping could be made a .csolution level.

That's why I proposed the notation of context map (https://github.com/Open-CMSIS-Pack/devtools/issues/450#issuecomment-1282563745)

[jkrech]

!!! Updated: now covers full solution content !!! 2022-11-15 @tcsunhao, could you please review the snippet from csolution.yml.

# yaml-language-server: $schema=https://raw.githubusercontent.com/Open-CMSIS-Pack/devtools/schemas/projmgr/1.3.0/tools/projmgr/schemas/csolution.schema.json

solution:
  target-types:
    - type: mdk
      compiler: AC6

  build-types:
    - type: debug
      context-map:
        - context: hello_world_cm7.flexspi_nor_debug
      defines:
        - DEBUG
      misc:
        - compiler: AC6
          C-CPP:
            - -O1
            - -g

    - type: release
      context-map:
        - context: hello_world_cm7.flexspi_nor_release
      defines:
        - NDEBUG
      misc:
        - compiler: AC6
          C-CPP:
            - -Oz

  output-dirs:
    outdir: ./$Project$/$TargetType$/$BuildType$
    rtedir: ./RTE/$TargetType$

  projects:
    - project: ./cm4/hello_world_cm4.cproject.yml
    - project: ./cm7/hello_world_cm7.cproject.yml

When you specify the context hello_world_cm7.release+mdk this will be mapped to hello_world_cm7.flexspi_nor_release+mdk All projects with the same build-type/target-type from the csolution belong together. .release+mdk hello_world_cm4.release+mdk hello_world_cm7.flexspi_nor_release+mdk

[tcsunhao]

Hi @jkrech , I am confused about where the flexspi_nor_release of hello_world_cm7 is defined. Can you give an example about that? It is strange that debug/release and flexspi_nor_release/flexspi_nor_debug are defined in different places.

[jkrech]

Hi @tcsunhao, note that flexspi_nor_release is not specifically defined but is mapped. This means that the settings for build-type=release are the same provided to flexspi_nor_release.

[tcsunhao]

Hi @tcsunhao, note that flexspi_nor_release is not specifically defined but is mapped. This means that the settings for build-type=release are the same provided to flexspi_nor_release.

I think there might be limitation with this approach: what if flexspi_nor_release settings are different from release? This is not definition but rename. Please note that in hello_world_cm7.cproject, there is following definition:

    - group: linker
      files:
        - file: ./MIMXRT1176xxxxx_cm7_flexspi_nor.scf
          for-type:
          - .flexspi_nor_debug
          - .flexspi_nor_release
          for-compiler: AC6

The flexspi_nor_debug and flexspi_nor_release is used for linker.

[jkrech]

In case of build type debug the cm7 cproject is "invoked" with the build-type name flexspi_nor_debug so the linker file selection would work as expected.

[tcsunhao]

Honestly, I think this way is rename, not definition. I agree that this way can meet this hello_world_cm4/hello_world_cm7 cases, but the real embedded world has no restriction, different build types can have different data which cannot be supported by the proposal.

I prefer some ways like

  projects:
    - project: ./cm4/hello_world_cm4.cproject.yml
      assign-build-types:
        - type: debug
        - type: release
    - project: ./cm7/hello_world_cm7.cproject.yml
      assign-build-types:
        - type: flexspi_nor_debug
          build_with: hello_world_cm4@debug
        - type: flexspi_nor_release
          build_with: hello_world_cm4@release

Definition and invocation are separated.

[jkrech]

@tcsunhao In your example above we have build types: debug release flexspi_nor_debug flexspi_nor_release

Which projects get build when I specify to build the configuration "release"? From the description above I think hello_world_cm4 is the only project associated with "release" as it has no build_with assignment. If I select "flexspi_nor_release" then the tool should build hello_world_cm7 with "flexspi_nor_release" build-type hello_world_cm4 with "release" build-type.

[tcsunhao]

@jkrech , your understand is correct. When 'release' is specified, then only hello_world_cm4 release is build and it can build passed.

[ReinhardKeil]

Now reflected in https://github.com/Open-CMSIS-Pack/devtools/pull/642

[ReinhardKeil]

context-map: is now part of the specification. @tcsunhao if all OK from your end, we should start implementing. See here https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Input-Format.md#context-map

[tcsunhao]

Hi @ReinhardKeil, we are ok with this design. Thank you very much.

[jkrech]

see cmsis-toolbox 2.0.0-dev0