Fix application profile link mess

[ccli8]

Summary of changes

This PR tries to address #407, including:

1. Provide one approach to address cmake link mess with mbed-core-flags/
   mbed-rtos-flags whose links or not depends on selected application profile,
   full or bare-metal.
   1. Add target config option application-profile for application to
      select which application profile to use. Applications are responsible
      for make this target config option consitent with link selection of
      mbed-os/mbed-baremetal.
   2. Add cmake interface library mbed-application-profile-flags. It is to
      substitute for mbed-core-flags/mbed-rtos-flags. Library camke targets
      should change to link this one to build upon correct application profile
      selection.
2. All in-tree library targets link mbed-application-profile-flags instead of mbed-core-flags/mbed-rtos-flags to build upon correct application profile.

Impact of changes

To link mbed-baremetal, target.application-profile must be set to bare-metal in mbed_app.json5.

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

[multiplemonomials]

Woah, this is a lot to take on! Thank you for working on this!

Haven't looked at the code yet but just going on the description:

• Could we rename mbed-application-profile-flags to either mbed-os-flags or mbed-flags? Going to be typing that name 100000 times so I'd like it a bit shorter, and that doesn't lose information.
• We will need to provide an alias so that libraries and applications that use mbed-core-flags will still work. Luckily CMake makes that easy to do with add_library(ALIAS)

[ccli8]

Could we rename mbed-application-profile-flags to either mbed-os-flags or mbed-flags? Going to be typing that name 100000 times so I'd like it a bit shorter, and that doesn't lose information.

That's fine. Rename mbed-application-profile-flags to mbed-os-flags.

We will need to provide an alias so that libraries and applications that use mbed-core-flags will still work. Luckily CMake makes that easy to do with add_library(ALIAS)

There is compatible concern. My original idea is:

• new mbed-core-flags = old mbed-core-flags
• new mbed-rtos-flags = old mbed-rtos-flags
• added mbed-os-flags = old mbed-core-flags + old mbed-rtos-flags if target.application-profile isfull.

To achieve above compatible, updated idea would become:

• new mbed-core-flags = old mbed-core-flags + old mbed-rtos-flags if target.application-profile isfull.
• new mbed-rtos-flags = old mbed-rtos-flags
• added mbed-os-flags = new mbed-core-flags or become unnecessary

That is, mbed-core-flags is overloaded dependent on target.application-profile. And only one of mbed-os and mbed-baremetal target would be created dependent on target.application-profile, but not both. For example, when target.application-profile is full, mbed-baremetal cannot link mbed-core-flags because mbed-core-flags also links mbed-rtos-flags.
.

[multiplemonomials]

Makes sense to me! I definitely think that, depending on the application profile setting, we should make only the mbed-baremetal or mbed-os cmake targets available.

[ccli8]

Update as below:

1. Drop mbed-application-profile-flags (or its renamed versions mbed-os-flags). It is replaced with overloaded mbed-core-flags.
2. Overload mbed-core-flags/mbed-core-sources so that they will involve mbed-rtos-flags/mbed-rtos-sources or not, depending on target.application-profile setting.
3. All libraries must link mbed-core-flags and no mbed-rtos-flags, or the link mess issue remains.
4. Both mbed-os and mbed-baremetal are still created, but one will become invalid and get caught on application link, depending on target.application-profile setting.