search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

CMake: From USCRPL/mbed-cmake to Mbed OS first-party CMake #13981

Closed ladislas closed 3 years ago

ladislas commented 3 years ago

Description of defect

Intro

As mentioned in #13974, I'm in the process of moving our current project from USCRPL/mbed-cmake to mbed os first-party CMake.

I thought it might be interesting for others to share our progress, our questions, feedback and issues we might be facing. I think that github is better than the forum for this as it is easier to share code, other repos and reference issues and PR

Our project is quite complex, with a main src directory containing our product firmware (main program). We have different drivers and libraries that are being used by the firmware.

We also have a lot of spikes: standalone projects (with their own main.cpp) to test components, features, libs, technical solutions, etc.

The following repository is a simpler example of our big project, and I'll use it to test all the features.

https://github.com/ladislas/mbed-cmake-template

How it works now

USCRPL/mbed-cmake allows us to have the spikes and the main program live in the same repository and compile together without any issues. We then use openocd to flash the .bin we want to use in our product.

USCRPL/mbed-cmake first creates a mbed-os-static STATIC library (https://github.com/USCRPL/mbed-cmake/blob/c0b0f7d4080bba179b9390e877eb0c1e7467f6d0/cmake/MbedOS-GCCArm.cmake#L35-L37) which is then wrapped into an mbed-os INTERFACE that defined the linker script and link options (https://github.com/USCRPL/mbed-cmake/blob/c0b0f7d4080bba179b9390e877eb0c1e7467f6d0/cmake/MbedOS-GCCArm.cmake#L50-L58). It's this mbed-os INTERFACE that our main program, spikes drivers and libs link with.

From a user perspective, mbed-os-static is compiled once for the main program and for all the spikes, drivers and libs. Adding a new spike with just a main.cpp file, will only increment the whole compilation steps number by one.

First try with Mbed OS first-party CMake

On the other hand, mbed os first-party cmake "recompiles" all the needed sources for each target depending on it. Adding a new spike linking with mbed-os will throw in the compilation a few hundred more "steps". Looking at the output, one can clearly see that mbed os or target files are compiled multiple times for the libs, the spikes and the main program.

Issues

And then it stops as the way it handles the linker script is not made for multiple add_executable targets.

Another issue was that adding another executable and calling mbed_set_mbed_target_linker_script resulted in the following error about .compile_time_defs.txt:

CMake Error: Files to be generated by multiple different commands: "/Users/ladislas/dev/ladislas/mbed-cmake-template/build/compile_time_defs.txt"

The issue comes from here: https://github.com/ARMmbed/mbed-os/blob/33a7e66a0794c91fddc19f9217a81910d5f4a23f/tools/cmake/toolchain.cmake#L22-L23 and is easily fixed by using:

-    file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/compile_time_defs.txt" CONTENT "${_compile_definitions}\n")
-    set(${definitions_file} @${CMAKE_BINARY_DIR}/compile_time_defs.txt PARENT_SCOPE)
+    file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/${target}.compile_time_defs.txt" CONTENT "${_compile_definitions}\n")
+    set(${definitions_file} @${CMAKE_BINARY_DIR}/${target}.compile_time_defs.txt PARENT_SCOPE)

Note that the two files generated are identical. If they can never be different, it would be better to juste generate one and use it for all executable.

Questions

Please note I'm neither a CMake expert nor a .ld expert.

From my understanding: for the same mbed target (DISCO_F769NI in our case), the linker script is always the same. If we change target, we must change the linker script. In real life projects this happens seldom as your board/target is usually the same for a long period of time. But even if we need to change it, a new run of mbed-tools configure will provide everything needed.

Currently mbed-os, mbed-core, mbed-rtos are defined as INTERFACE libraries, meaning they are not compiled on their own (as static or object libraries would be), but become part of the target (other library or executable) that links with it.

So calling mbed_set_mbed_target_linker_script for each executable will also call mbed_set_toolchain_options multiple times.

My first question is:

What is the reason for using INTERFACE for the whole mbed-os? Why not use a static library wrapped in an interface?

And secondly:

Is supporting a project structure such as mine with multiple executable targets on the roadmap?

I'd be happy to help in this case.

Thanks for reading till here and also thanks for bringing CMake to mbed-os! :)

(cc @0xc0170 @hugueskamba @rajkan01 @multiplemonomials @ProExpertProg)

Target(s) affected by this defect ?

DISCO_F769NI

Toolchain(s) (name and version) displaying this defect ?

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

What version of Mbed-os are you using (tag or sha) ?

33a7e66a0794c91fddc19f9217a81910d5f4a23f

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed --version
1.10.4

mbed-tools --version
3.5.1.dev36

How is this defect reproduced ?

to do

multiplemonomials commented 3 years ago

I haven't had a chance to poke around the official CMake scripts that much, but I do agree that building the linker script multiple times seems like the wrong way to do it since it doesn't change. It would be better to just generate it once and then attach it as part of a target's link flags (how mbed-cmake does it).

Also, it definitely doesn't seem right if the entire source code is getting built once for each target. My understanding is that the mbed source code is supposed to get built as an object library, then the objects are supposed to get attached using TARGET_SOURCES to an interface library. But it sounds like maybe the source files themselves got added as the interface sources, rather than the object files.

ciarmcom commented 3 years ago

@ladislas thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided. Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de or a single valid release tag of the form mbed-os-x.y.z . E.g. 'master' is not a unique single snapshot. NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

ciarmcom commented 3 years ago

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2888

ladislas commented 3 years ago

My understanding is that the mbed source code is supposed to get built as an object library, then the objects are supposed to get attached using TARGET_SOURCES to an interface library.

@multiplemonomials it was since https://github.com/ARMmbed/mbed-os/commit/e7c0d93ad4b2eee09a16d22d91452ee3eaad2185 that changed it from OBJECT to INTERFACE.

Would OBJECT be better than STATIC libraries?

multiplemonomials commented 3 years ago

Yeah that commit is... not right, or at least it's not correct to the design we originally planned (I worked with Martin and Hugues to plan out how the object and interface libraries would be used). The interface libraries do need to be there, but there also need to be object libraries as well. The object libraries would be used to compile the sources, then the compiled objects from those libraries should get added via target_sources to the interface libraries.

0xc0170 commented 3 years ago

Thanks for the feedback, we will review and respond to all issues/questions.

0xc0170 commented 3 years ago

@ladislas can we convert example blinky to be able to reproduce the issue with spikes? I've checked your template repository, it does not reference mbedtools, so I might need an assistance to reproduce it there (how to).

Is supporting a project structure such as mine with multiple executable targets on the roadmap?

I would say it should work as CMake libraries should be reusable. We are currently looking at testing and it might be the same use case.

  1. 2 or more applications 2 spikes as you call, just 2 different applications using the same mbed-os library ? I've created a branch with 2 main object libraries to test with https://github.com/0xc0170/mbed-os/tree/cmake-fix-objects - can you test ?

  2. linker issue we will review if we can fix the linker not to be dependent on application target (it's related to the first one so we might want to first fix that and then get to this one).

We initially worked only on object libraries but we faced cmake issues with object libraries (we should be able to find PRs/commits) and converted to interface libraries. We exposed the main libraries mbed-os and mbed-baremetal as interface as well - it has some drawbacks as mentioned here, we should be able to address them. The branch I shared above was a concept we had previously.

From my understanding: for the same mbed target (DISCO_F769NI in our case), the linker script is always the same. If we change target, we must change the linker script. In real life projects this happens seldom as your board/target is usually the same for a long period of time. But even if we need to change it, a new run of mbed-tools configure will provide everything needed.

Consider ld file being a template that is changed based on app needs (sections could be adjusted, an example is bootloader). Therefore we preprocess linker scripts. If you change an app, linker script must be regenerated - reusing the same template. We always wanted to have one .ld template and fill it in. Also for linker script file, if you can provide us a repo where we can reproduce, we will review in more detail.

ladislas commented 3 years ago

can we convert example blinky to be able to reproduce the issue with spikes? I've checked your template repository, it does not reference mbedtools, so I might need an assistance to reproduce it there (how to).

@0xc0170 yes, I'll work on a PR! I'll also push to my template on a specific branch for testing.

I'll also test your branch and let you know.

And thanks for the explanation on the linker file. 👍

multiplemonomials commented 3 years ago

Okay, I've got time to take a look into what's going on here. I think I found the source of some of these errors, but before that, I got distracted by a giant, horrible, flashing red flag:

Detecting C Compiler ABI -- Failed

This is the same issue that we talked about at our meeting, and it seems that it still hasn't been fixed. Basically, the compiler flags that CMake is using to do all of its internal tests are extremely messed up, and you guys just papered over the issue with:

set(CMAKE_C_COMPILER_WORKS TRUE)
set(CMAKE_CXX_COMPILER_WORKS TRUE)

This is a really bad idea, because it means that all sorts of things will be subtly screwed up later on, since CMake cannot successfully run compilation or linking tests. The real way to fix it is to add the needed compiler flags to CMake's global flag variables, like I explained. So, I made a PR to fix this: https://github.com/ARMmbed/mbed-os/pull/13987 . Please take a look when you have a chance!

multiplemonomials commented 3 years ago

@ladislas When you submit your PR, this also needs to get fixed in mbed-os/CMakeLists.txt:

- COMMAND "arm-none-eabi-cpp" ${_linker_preprocess_definitions} -x assembler-with-cpp -E -Wp,-P
+ COMMAND ${CMAKE_CXX_COMPILER} ${_linker_preprocess_definitions} -x assembler-with-cpp -E -Wp,-P

The existing code requires arm-none-eabi-cpp to be on the PATH, which is not guaranteed. Instead, it's better to use the compiler that we already know the path to. The options -x assembler-with-cpp -E are enough to convert the compiler into a preprocessor.

multiplemonomials commented 3 years ago

Update: I understand a little better why the current method was used (compiling all mbed sources for each target). The issue is that you have a set of base Mbed sources, mbed-core. You also have a number of extra modules, like mbed-rtos. However, these extra modules can add extra compile definitions (such as MBED_CONF_RTOS_PRESENT) that change the behavior of source files in mbed-core. This means that you can theoretically end up with a different product in mbed-core depending on what extra modules you link.

IMO, this is somewhat bad code design to have things tightly coupled like this, and it's hard to fix at the build system level. However, I also don't think it's a good solution to require rebuilding all mbed sources for each target. For now, I'm going to try at least making mbed-baremetal and mbed-rtos separate libraries to fix that dependency, but I'm not sure how many extra modules have this behavior.

multiplemonomials commented 3 years ago

OK! I think I figured out a method that works to fix this. @ladislas Check my branch here: https://github.com/multiplemonomials/mbed-os/tree/cmake-object-libs It should fix your issue, I've converted mbed-os, mbed-baremetal, and mbed-storage-kvstore to the new system so they should only get built once regardless of how many targets they're used in.

I realize that the solution I told you guys originally doesn't actually work given the constraints above. However, I figured out something that should work for what you need.

For the main OS targets, I used this strategy:

For extra modules, I used this strategy:

Note that this process makes some assumptions:

Let me know what you think about this plan -- I'm hoping that it can make life easier for us users. But if it seems totally unworkable, let me know as I have another idea that might also be feasible.

0xc0170 commented 3 years ago

Thanks @multiplemonomials , we will review but most likely the next week (some of us are out of office in the next days)

0xc0170 commented 3 years ago

I run initial compiler checks to see what flags and files get into the app. I'll look at the structure the next week.

Compiling K64F for GCC ARM shows startup is duplicated:

arm-none-eabi/bin/ld.exe: CMakeFiles/mbed-os-example-blinky.dir/mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/startup_MK64F12.S.obj: in function `__isr_vector': (.isr_vector+0x0): multiple definition of `__isr_vector'; mbed-os/CMakeFiles/mbed-os-obj.dir/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/startup_MK64F12.S.obj:(.isr_vector+0x0): first defined here

ARMClang:

OOLCHAIN_ARM_STD\startup_MK64F12.S
armclang: error: ARM Compiler does not support '-mcpu=Cortex-M4-mcpu=cortex-m4'
armclang: error: ARM Compiler does not support '-mcpu=Cortex-M4-mcpu=cortex-m4'
armclang: error: armasm does not support CPU 'cortex-m4-mcpu=cortex-m4'
armclang: error: armasm does not support FPU 'unknown'

@ladislas if you can share the multiple target example, or we shall create our own to test the fix?

multiplemonomials commented 3 years ago

Oh whoops, there was an issue where the wrong linker script path was passed for GCC_ARM. I pushed a new commit to #13987 to fix it. I also found a variable name conflict with the profile scripts that was probably causing the arm compiler error, pushed a fix for that too.

ladislas commented 3 years ago

if you can share the multiple target example, or we shall create our own to test the fix?

@0xc0170 yes, I'm working on a simple example, I'll share it later today.

ladislas commented 3 years ago

@multiplemonomials @0xc0170

Alright, I've setup a working example of our project structure, available here:

https://github.com/ladislas/mbed-cmake-template/tree/feature/move-to-vanilla-cmake

Instructions are available here:

https://github.com/ladislas/mbed-cmake-template/tree/feature/move-to-vanilla-cmake#-wip---from-uscrplmbed-cmake-to-mbed-os-first-party-cmake

If you want to compare the same template with USCRPL/mbed-cmake, you can follow the instructions in develop

https://github.com/ladislas/mbed-cmake-template#how-to-use

multiplemonomials commented 3 years ago

OK @ladislas I tested your example, and my cmake-object-libs branch that I linked earlier is able to compile it correctly with no other changes and only 247 files compiled.

ladislas commented 3 years ago

@multiplemonomials that's great news, I've just tested it myself and I can confirm it compiles both the main src and the spike without any problems :)

The number of files to compile (spike + lib + src) is also much lower than it was previously:

multiplemonomials commented 3 years ago

@0xc0170 @hugueskamba Have you had a chance to look at my cmake-object-libs branch? I think it's an important change to make but it might be too much of a project for me to do by myself, I was hoping you could take the ideas from it and make a PR that implements it.

0xc0170 commented 3 years ago

I was looking for the reference this week and could not find it in PRs, it's on a branch! I'll create a task for the next sprint to look at it.

@ladislas Check my branch here: https://github.com/multiplemonomials/mbed-os/tree/cmake-object-libs

got it now!

ladislas commented 3 years ago

@multiplemonomials Any chance you could rebase your branch on top of master?

multiplemonomials commented 3 years ago

You go ahead... that would be a huge project as it touches hundreds of CMakeLists

ladislas commented 3 years ago

😂

0xc0170 commented 3 years ago

@multiplemonomials I started looking at the branch this week.

I wonder if there is not a simpler way to achieve the object library (I assume this split flags vs obj is due to our RTOs injections or ?). I can't think of any at the moment :( We tried couple previously and always hit an issue somewhere in CMake (known issue usually found in their tracking list).

The concept looks good, wondering how to start applying this with upcoming targets refactors. Can we leave targets as they are and refactor the rest and then targets once they are done?

Thanks for putting this together !

multiplemonomials commented 3 years ago

I wonder if there is not a simpler way to achieve the object library (I assume this split flags vs obj is due to our RTOs injections or ?). I can't think of any at the moment :( We tried couple previously and always hit an issue somewhere in CMake (known issue usually found in their tracking list).

I remember that I tried stuff like that, I worked off and on for a couple days and this was the simplest method I could come up with. But to be honest, I don't remember the specific reason that this doesn't work.

The concept looks good, wondering how to start applying this with upcoming targets refactors. Can we leave targets as they are and refactor the rest and then targets once they are done?

I think it will have to work like this (using LPC1768 for example):

0xc0170 commented 3 years ago

Why can't we just use intermediate object library that would link to interface libraries in the tree. The same way the application does it now but moving it down to Mbed OS lib. Me naively thinking how this could work, of course does not, a question is: can it? It seems the Mbed OS object lib is built (253 files I get with the @ladislas example), but the includes and symbols are not exposed as I link to interface libs with PRIVATE. Otherwise all gets propagated to the app. Here's the change:

add_library(mbed-os OBJECT)
target_sources(mbed-os PRIVATE dummy.cpp)

target_link_libraries(mbed-os
    PRIVATE
        "$<BUILD_INTERFACE:mbed-rtos>"
        "$<BUILD_INTERFACE:mbed-core>"
)

I would need something similar what is done in with mbed-base-flags interface libs: target_link_libraries(mbed-os INTERFACE mbed-base-flags mbed-rtos-flags) to propagate flags to the app.

Isn't there another way doing this? Basically getting include paths and symbols up to the app as they are required to be used with the objects generated.

multiplemonomials commented 3 years ago

I think what you're describing is actually really similar to what I proposed here: https://github.com/ARMmbed/mbed-os/pull/14199#issuecomment-771288853

It does work but you have to use a somewhat more complicated method to get all of the flags right.

ladislas commented 3 years ago

I've tested the mbed_create_distro solution provided by @multiplemonomials here: https://github.com/ARMmbed/mbed-os/pull/14199#issuecomment-771288853

I can confirm it works amazingly well with 6.7.0, but not with master. It handles the different executables well, compiles mbed-os only once and links everything correctly.

How could we move forward to integrate that in here?

0xc0170 commented 3 years ago

I started prototyping both approaches shared here to see how they play together with Mbed Os targets.

https://github.com/0xc0170/mbed-os/tree/cmake-object-libraries-with-interface - this is similar to cmake-object-libs. It's based on post target refactoring. I ported mbed-core, rtos and events. The main component is interface library and objects are under xxx-obj. They are then connected together so I can just link to interface library and work with it via util function mbed_attach_object_lib_with_interface_lib

I've hit two issues so far. I ported the simplest target I found quickly: mbedtools compile -m MAX32620FTHR -t GCC_ARM

  1. mbed_sdk_boot file does not see MBED_CONF_RTOS_PRESENT although the file Thread.cpp for instance in the same CMake target (mbed-core-obj) does. For now, I empty that file as I am testing with mbed-os (it should be moved to baremetal most probably so I can fix that separately). But still curious why the definition is not visible within the same CMake target.

  2. object library cyclic deps - not supported in CMake yet, known issue. we got mbed-core and Mbed OS target - both depend on each other. One way would be to use just interface libraries for Mbed OS targets - do some magic to copy sources and expose the rest to mbed-core that needs it and also an application. Or any idea how to break this? This is basically the same issue as we would have with target_link_libraries(mbed-baremetal-obj TARGET_LPC1768) as shared earlier. Both of these depend on each other.

Update later on 23.2: the first still stays. Similar issue is with our rtos C++ files that require to see MBED_CONF_RTOS_PRESENT macro. The second I resolved. Core only needs to see headers so INCLUDE_DIRECTORIES from target. The deps can be broken.

ladislas commented 3 years ago

This is basically the same issue as we would have with target_link_libraries(mbed-baremetal-obj TARGET_LPC1768) as shared earlier. Both of these depend on each other.

Do you know exactly what those two need from each other? Maybe the dependencies can be abstracted away.

0xc0170 commented 3 years ago

From what I recall:

mbed-core needs three main things from target: get device header file for HAL/drivers, cmsis/platform needs target's file via cmsis.h - MCU header file where you can find cmsis and core things and mbed rtx header file.

target needs core util functions from core (critical section), error or toolchain, hal declarations and some others possibly. target implements functionality from core.

We could potentially break core's dependency on targets, we would just need to abstract the things core would like to get from target.

ladislas commented 3 years ago

@0xc0170 what's your take on merging @multiplemonomials's work around for the time being? It would solve advanced users use cases while not changing anything for the others as both solution could co-exist.

This will give us ample time to find a more suitable solution as it will let us experience the real first party cmake provided by Mbed OS through more advanced setups.

0xc0170 commented 3 years ago

I would like to get better overview with options so all of us can agree on what we can do for the March release. We should be able to fix it one way or another.

0xc0170 commented 3 years ago

@multiplemonomials I've just pushed an update. I could not figure out that silly dependency we have with rtos and core files. I tried various things but the only way it worked so far was using your approach with mbed-os-obj and copy core files over and build it all together with rtos flags. To keep the discussion in one place, I created a pull request to my fork: https://github.com/0xc0170/mbed-os/pull/21

0xc0170 commented 3 years ago

Anyone interested, feature branch feature-cmake-object-libraries should fix this issue, we are still developing it so it's work in progress and rebase often.

ladislas commented 3 years ago

Thanks a lot @0xc0170 ! As discussed, it works now perfectly for our setup. Should you make a PR to master so that we can review?

If anyone is interested to try it out, I've updated my template:

# clone repo
git clone https://github.com/ladislas/mbed-cmake-template

# checkout branch
git checkout --track origin/feature/move-to-vanilla-cmake

# clone mbed
make mbed_clone BRANCH=feature-cmake-object-libraries

# config
make config

# build
make
wmmc88 commented 3 years ago

I'm interested in being able to compile multiple different binaries from a single mbed project, just like @ladislas example repo. Any chance feature-cmake-object-libraries is getting merged into mainline soon?

0xc0170 commented 3 years ago

I'm interested in being able to compile multiple different binaries from a single mbed project, just like @ladislas example repo. Any chance feature-cmake-object-libraries is getting merged into mainline soon?

We had to switch back to the planned work we got: support all targets, have them green in CI, write docs and enable tests (unittests and greentea). There is storage left to be ported and then tested.

We will keep the branch rebased often.

We need to still port storage and clear build errors and carefully test as there are some workarounds we had to use (object libs are not first citizen still unfortunately).

Contributions are welcome, more testing we get better.

multiplemonomials commented 3 years ago

btw, you can use this patch to get the functionality you want with release versions: https://github.com/ARMmbed/mbed-os/pull/14274

boraozgen commented 3 years ago

I stumbled upon this thread when I noticed that I cannot add compiler options only for my code without adding them to mbed-os. AFAIU, interface libraries are compiled with the options of the target, i.e. the compiler options apply to all linked interface libraries. Object libraries would solve this issue too.

ladislas commented 3 years ago

@0xc0170 where are we on that matter? :)

0xc0170 commented 3 years ago

The state stands as it was, it is on hold for now (https://github.com/ARMmbed/mbed-os/issues/13981#issuecomment-802049614). We most likely can resume the work in Q3.

I am happy to help meanwhile if there are any contributions for the feature branch. I'll rebase the feature branch tomorrow to bring it up to date after unittests changes.

multiplemonomials commented 3 years ago

@boraozgen Note that my patch I submitted for #14274 will provide a workaround for that issue, and you may even just be able to drop mbed_create_distro.cmake into your project and go without changing Mbed source files in the latest version.

0xc0170 commented 3 years ago

We hope to get #15126 into master and close this issue.

ciarmcom commented 3 years ago

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.

ladislas commented 3 years ago

15126 has just been merged, we'll start moving to vanilla m bed cmake next week. I'll keep you posted here.

Maybe it's good to reopen until the transition is over.

0xc0170 commented 3 years ago

The discussion can be ongoing here. If there are any other issues, you can report via a new bug report.

ladislas commented 2 years ago

We are currently trying to move from USCRPL/mbed-cmake to Mbed's "vanilla" CMake.

https://github.com/leka/LekaOS/pull/397

The process is not as straight forward as I hoped it would be, compared to setting up USCRPL/mbed-cmake in the first place.

I'll report the issues here and open new ones if needed:

Conclusion on 2021/12/31:

After spending 48h hours on this, I was hoping the transition would be easier. I'm a bit disappointed by the fact that compilation and linking are so long. The modularity CMake should bring is not there. This is mostly due by the use of INTERFACE everywhere. create_distro helps a bit, but it's still not the CMake way.

CMake target naming could be improved. drivers are in mbed-core, mbed-rtos is actually not the rtos directory but more the CMSIS/RTOS2 part. rtos is part of mbed-core. This is all very confusing for people digging deeper. mbed-rtos could be renamed mbed-cmsis-rtos, drivers directory could have it's own target mbed-drivers or even be separated in sub-drivers, like mbed-drivers-i2c, etc.

Right now, I'm not sure what to do. Should I keep fighting the tools or keep our current setup using USCRPL/mbed-cmake?

Our product will be on the market in one month, and as much as I would like to help improve mbed, I'm not sure we have the time and resources right now.

Again, a clear roadmap about what to expect in the coming month would really help us.

multiplemonomials commented 2 years ago

Wait, so create_distro() didn't work to reduce the compile time for building multiple targets? Is it because there are more source files than the corresponding mbed-cmake project? Or is it that you had to make multiple distros for things with different functionality?