Different configurations of different build-types to support in multproject csolution

[tcsunhao]

For csolution yml with multi projects, build-types are shared and can only be shared.

NXP data for multiproject example, each project has its own data suit copy, to map into csolution/cproject, then we need merge hello_world_cm4 and hello_world_cm0plus data into one copy. This requests 2 projects data should be mergeable which means they shouldn't have its own data related to build-types.

If one project has its individual different build-type settings which the other project doesn't have. Then existing csolution yml cannot specify it.

For example, project1 and project2 are in one csolution.yml, project1 needs to include bin of project2. project1 depends on a special component, for its configuration, XXDEBUG is needed under "Debug" build-target, XXNDEBUG is needed under "Release" build-target, there is no such XXDEBUG/XXNDEBUG macro definition needed in project2. It looks like there is no good way to support such case in existing csolution/cproject mechanism. If you record XXDEBUG under "Debug" build-type, then both project1 and project2 will get it.

This is kind of corner case, but it may happen.

[jkrech]

@tcsunhao this is a good use case we should further think about. At this point e.g. the defines can be set on a cproject level for the whole project but not for a specific build- or target-type. This can only be done for individual components, groups or files. Good catch.

[VGRSTM]

@tcsunhao I guess a way to do would be (not supported right now) if cproject to rely on undefines / defines supporting for-type / not-for-type statements if useless / missing defines promoted at csolution level.

Such said I'm not fully comfortable with.
I'm thinking build-types would have to be defined at cproject level. Would help too to support "shared" cproject dependency if multiple csolution (common code reuse from one application to another).
Issue if it will most probably fully break today processing promoting all possible combinatory at csolution level based on target-types & build-types
Possibly to be part of related #356 #348 outcomes. I'm asking myself a bit same as you:

However, there is a defect in such way, per my understand that, cproject is used to define project contents. csolution is used to define solution. So one cproject may need to be used in many csolutions. So if we used targets defined in one csolution in cproject, then if other csolution uses this cproject again, then it may needs to update the cproject yml data. This coupling between cproject and csolution affects the reuse of cproject.

To me your highlight is not a corner case but a common case ... today nothing sounds impossible but requires to get proper understanding of under the hood mechanism. I'm asking myself a bit a bout UX ([projmgr] Do we foresee GUI based proposal on YML specification integration ? .
If multi core or secure / non secure csolution end user needs to define generic (i.e. common setup to all cproject children) build-types at csolution level then to refine such common setup per cproject.

[tcsunhao]

According to yesterday meeting, setups can be a way to support such case that projects inside one solution don't share the same configuration(Marco, compiler flags)
Let me describe the case here again:

1. multicore device example
2. 2 projects: hello_world_cm4 and hello_world_cm0plus, hello_world_cm4 needs to include binary of hello_world_cm0plus
3. Both hello_world_cm4 and hello_world_cm0plus have "Debug" and "Release"
4. hello_world_cm4: In "Debug", needs marco "XXDEBUG", flags "-g". In "Release", needs macro "XXNDEBUG", flags "-Os"
5. hello_world_cm0plus: In "Debug", needs marco "DEBUG". In "Release", needs macro "XXDEBUG", flags "-Oz"
   Then
   in hello_world_cm4 cproject yml

  setups:
    - setup: Arm Compiler 6 project setup
      for-compiler: AC6
      for-type:
        - .Debug
      linker:
        - script: ./mdk/xxx.scf
      define:
        - XXDEBUG
      misc:
        - compiler: AC6
          C:
            - g

    - setup: Arm Compiler 6 project setup
      for-compiler: AC6
      for-type:
        - .Release
      linker:
        - script: ./mdk/xxx.scf
      define:
        - XXNDEBUG
      misc:
        - C:
            - Os

In hello_world_cm0plus yml

  setups:
    - setup: Arm Compiler 6 project setup
      for-compiler: AC6
      for-type:
        - .Debug
      linker:
        - script: ./mdk/xxx.scf
      define:
        - DEBUG

    - setup: Arm Compiler 6 project setup
      for-compiler: AC6
      for-type:
        - .Release
      linker:
        - script: ./mdk/xxx.scf
      define:
        - NDEBUG
      misc:
        - C:
            - Oz

This is the only way which I think which can work for NXP multiproject example case based on existing Open-CMSIS-Pack mechanism.
I have to say that here are some small defects in this way:

1. duplication in linker, I have to write it in each "for-type"
2. kind of couple cproject and csolution because of "for-type" which means limit the direct invoke of project.yml.

[ReinhardKeil]

@tcsunhao thanks for raising it. I think we should clearify that setups are additive.

This simplifies it to:

  setups:
    - setup: Linker script for Arm Compiler 6
      for-compiler: AC6
      linker:
        - script: ./mdk/xxx.scf
 
    - setup: Build mode Debug
      for-type:
        - .Debug
      define:
        - XXDEBUG
      misc:
          C:
            - g

    - setup: Build Mode release
     for-type:
        - .Release
      define:
        - XXNDEBUG
      misc:
        - C:
            - Os

However in principal your solution works too.

[tcsunhao]

Thank you @ReinhardKeil for pointing duplication linker data. I will use setup for such cases then until we have a better one.

[tcsunhao]

We just realize that there is a real case in NXP for multiple project solution, project target pair is with different target name.
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.

Something like for-project is needed(By default, if for-project is not provided, it means support all build-targets support all projects)

[jkrech]

@tcsunhao, I cannot see how the for-project construct would solve your problem. If I understand your request correctly you want to be able to define a named "group" for a set of contexts.
group "debug" would contain contexts: flexspi_nor_debug and debug
group "release" would contain contexts: flexspi_nor_release and release
At the command line of the tools you would specify the group name rather than the contexts.
I wonder what is the benefit of naming the type: flexspi_nor_debug instead of debug in project hello_world_cm7 in the first place. I find this is getting too complicated.

[tcsunhao]

@jkrech yes you are right, just "for-project" cannot meet my requirement. What I need, as you tell, it is the relationship between build-types of 2 projects(under one solution).
flexspi_nor_debug directly tells customers that this cm7 master example boot from flexspi nor flash. The cm4 image will be included into cm7 binary and copied into ram to run at some stage, just debug is enough.
In NXP MCUXpresso SDK, many multicore examples have this "different name" target pair case.

[VGRSTM]

@jkrech & @tcsunhao please comment if off track myself. I may have same concerns as you @tcsunhao.
Let's expose first my usage vision if cproject & csolution:

• cproject is reflecting a container leading to a binary generation. This binary can be an executable or a library.
• csolution is reflecting a container describing an end user application (on target running code serving a end customer business / need) "only" doing assembly of cproject collection (collection length is >= 1). No functional code is hosted by csolution.
  This way cproject has to be a self contain container to me because can be reused from one application (i.e. csolution to another (let's think about a boot loader or static library project).

If self contain cproject is requiring to me to define under its own build-types what today only possible if csolution.
Today reason to get build-types at csolution level is we need from top to build all target-types & build-types combinatory. Drawback is such is forcing all csolution children (i.e. cproject) to share same build-types ... here we come to your concern @tcsunhao and mine about cproject reusability ...

I'm thinking we have to find a way to host build-types definition at cproject level instead csolution one. Then at csolution level a way to describe explicitly today systematic under the hood target-types & build-types combinatory resolution.

[ReinhardKeil]

@tcsunhao & @VGRSTM thanks for sharing your concerns regarding target and build types. @VGRSTM I like your definition of cproject and csolution a lot, and consider to re-use it in the docmentation.

A potential solution is outlined here: #450
We should discuss this next week.

[ReinhardKeil]

could we continue discussing this under #450

[jkrech]

Closing this issue in favor of #450