I did configure this using cmake without any problem.
I thought I could just use it on the freertos example, but It's not that simple.
We need to have an exemple/template for this case I guess.

Hmm, I I think I need to update the README. I used it in the freeRTOS example I think. But I would put this in a different PR. Or do you want it as part of this one as well? The example might also require #222

The following lines

if(NOT CMSIS_FIND_COMPONENTS_RTOS)
    set(CMSIS_FIND_COMPONENTS_RTOS ${CMSIS_RTOS})
endif()

cause CMake to always add RTOS and RTOS_V2 components if none are supplied for CMSIS. I'm not fully sure whether this is the best solution.

Hmm, I I think I need to update the README. I used it in the freeRTOS example I think. But I would put this in a different PR. Or do you want it as part of this one as well? The example might also require #222

We try to have the documentation aligned with code changes. So for us it's fine and recommended to you add (related) example and readme updates in same PR. But if you prefer to have a different PR and you link both we will merge them together. Note that in this case we would not merge this one faster if it is finished and the documentation PR is not.

I will add some more documentation about how to use the namespace feature

Okay, I think the namespace feature also requires #190 , so it does not really make sense to merge my updated version without it. I would suggest that this is merged first, it is tested as well.

@rmspacefish Please take no offence but you have 5 PR opened (some are Independent) who rely on/use 2 other PR from someone. From what we have seen with @Hish15 everything is use full but I it takes time to test and review everything and we have discussions in all PR at a time. Please could you clearly identify the merge order and dependency in top comment (use edit) of every PR ? This way we will be able to focus for the reviews.

Also each PR should contain documentation/example related to the new features introduces by the PR. However if for some reasons you feel like several PR (feature separated from big example) are better for one feature (and we like short PR with @Hish15 ) then we can create a feature branch for you and you can merge your N PR into this feature branch before merging to master.
I created this branch especially for you if you want to change destination of some PR : https://github.com/ObKo/stm32-cmake/tree/feature/RTOS

Understandable. It's not an issue if it takes bit longer, you merged a lot of PRs lately after all :-) My goal is make my fork and the upstream equal quickly, so there is a lot content with the dependencies getting complicated (lwip relies of CMSIS content as well). If your prefer short PRs, N feature in one is maybe not ideal, because the PR might get large. I can merge my PRs into it in a logical order and then you can decide whether it's better to merge it in one go

If your prefer short PRs, N feature in one is maybe not ideal, because the PR might get large. I can merge my PRs into it in a logical order and then you can decide whether it's better to merge it in one go

Only one feature per feature/ branch. The idea is maintainers review and merge N PR that have dependencyinto feature/ branch. In this case you are allowed to not have documentation or to break things temporary. The final PR from feature/ to master is only to check everything is there and works but we do not review the code again as it's already done in the other PRs :)

Most help full point would be clearly identify the merge order and dependency in top comment (use edit) of every PR

Whether you use the feature branch or not is up to you. No pressure, we are open.

Okay. I think the best approach would be to simply have a PR for the full feature set, including documentation and example. This also makes testing easier. See #227