Provide alternative approach for consuming freeRTOS by cmake projects#1397
Provide alternative approach for consuming freeRTOS by cmake projects#1397eMKa94 wants to merge 1 commit intoFreeRTOS:mainfrom
Conversation
|
|
Hi, could you describe the use case you are looking for? I'm concerned about adding more options to the cmake adding maintenance overhead. |
I've described it a bit here. It is not only my personal issue... Current FreeRTOS internal CMake is not quite friendly for projects that define multiple different targets ( Like maintaining an ecosystem with many different devices, which is quite common in many companies... ). Reconfiguring the whole CMake project just to set a different port, heap strategy, or simply different compile options is a huge overkill. My simple solution provides a way to reuse kernel files and select port/heap files per target as many times as the user wants within a single CMake configure operation.... In other words... add_subdirectory(FreeRTOS) does not need to have HEAP / PORT CMake variables. And any target that need freeRTOS simply link what it needs and have a correct setup with a single CMake Configure operation. I've decided to share it since a lot of people were saying that it will be cool to have it in the official branch... |
2 participants
Description
Provide possibility to consume freeRTOS sources as CMake Interface libraries without compromising existing solution.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.