-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to not include heap in CMakeLists.txt #595
Changes from all commits
cdb854f
90ef953
f22169d
8c9b032
2aff1a1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -273,22 +273,26 @@ target_compile_options(freertos_kernel PRIVATE | |||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
######################################################################## | ||||||||||||||||||||||||||||||
add_subdirectory(include) | ||||||||||||||||||||||||||||||
add_subdirectory(portable) | ||||||||||||||||||||||||||||||
include(${CMAKE_CURRENT_LIST_DIR}/include/CMakeLists.txt) | ||||||||||||||||||||||||||||||
include(${CMAKE_CURRENT_LIST_DIR}/portable/CMakeLists.txt) | ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
target_sources(freertos_kernel PRIVATE | ||||||||||||||||||||||||||||||
croutine.c | ||||||||||||||||||||||||||||||
event_groups.c | ||||||||||||||||||||||||||||||
list.c | ||||||||||||||||||||||||||||||
queue.c | ||||||||||||||||||||||||||||||
stream_buffer.c | ||||||||||||||||||||||||||||||
tasks.c | ||||||||||||||||||||||||||||||
timers.c | ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
# If FREERTOS_HEAP is digit between 1 .. 5 - it is heap number, otherwise - it is path to custom heap source file | ||||||||||||||||||||||||||||||
$<IF:$<BOOL:$<FILTER:${FREERTOS_HEAP},EXCLUDE,^[1-5]$>>,${FREERTOS_HEAP},portable/MemMang/heap_${FREERTOS_HEAP}.c> | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/croutine.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/event_groups.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/list.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/queue.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/stream_buffer.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/tasks.c | ||||||||||||||||||||||||||||||
${CMAKE_CURRENT_LIST_DIR}/timers.c | ||||||||||||||||||||||||||||||
Comment on lines
+280
to
+286
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Revert back -improper use of CMake. No need to include CURRENT_LIST_DIR unless it is in a generate expression.
Suggested change
|
||||||||||||||||||||||||||||||
) | ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
# Check if user requested to not include a heap implementation | ||||||||||||||||||||||||||||||
if(NOT DEFINED FREERTOS_DO_NOT_INCLUDE_HEAP) | ||||||||||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps we should just not include a heap implementation if FREERTOS_HEAP is not set or set to 0? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure it will compile without the heap definitions. You will have linker issues with missing symbols. If you do not want a heap then create a custom heap source that errors out whenever the heap is used/consumed by the API it defines, and do: set(FREERTOS_HEAP "heap_disabled.c") Where void * pvPortMalloc( size_t xWantedSize )
{
(void)xWantedSize;
#if ( configUSE_MALLOC_FAILED_HOOK == 1 )
{
vApplicationMallocFailedHook();
}
#endif
return NULL;
}
/*-----------------------------------------------------------*/
void vPortFree( void * pv )
{
( void ) pv;
/* Force an assert as it is invalid to call this function. */
configASSERT( pv == NULL );
}
/*-----------------------------------------------------------*/
void vPortInitialiseBlocks( void )
{
}
/*-----------------------------------------------------------*/
size_t xPortGetFreeHeapSize( void )
{
return 0;
} If you want it in the FreeRTOS repo, then suggest making this an alternative heap implementation - as @paulbartell suggested and change the name to heap_0.c (NullOpt - a no-heap implementation of the heap API). - and place it with the other heap locations. Then you'd also have to change: $<IF:$<BOOL:$<FILTER:${FREERTOS_HEAP},EXCLUDE,^[0-5]$>>,${FREERTOS_HEAP},portable/MemMang/heap_${FREERTOS_HEAP}.c> To allow heap_0.c to be allowed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @paulbartell @jasonpcarroll thoughts? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just a note since I opened the issue #594: It will compile without linker issues if If adding the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still stand by my previous comment - adding an additional FREERTOS_HEAP option for the enumeration is better than adding yet another configuration for the same feature Since there is a linkage between FREERTOS_HEAP and SUPPORT_DYNAMIC_ALLOCATION then I suggest you make the linkage within the config via CMakeDependentOption - so that it is explicitly known that if SUPPORT_DYNAMIC_ALLOCATION is set to 1, you must configure FREERTOS_HEAP. Another method of fixing is to remove the SUPPORT_DYNAMIC_ALLOCATION and only use FREERTOS_HEAP=0 instead. That way you have the error/issue identified even before compile - when building up the configuration instead. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. configSUPPORT_DYNAMIC_ALLOCATION should be sufficient to deciding to include a heap implementation. The portable.h header should be changed so the heap functions are not declared when configSUPPORT_DYNAMIC_ALLOCATION==0. It does make sense to add a dependent section to the CMakeLists to make a heap selection IF configSUPPORT_DYNAMIC_ALLOCATION==1 THOUGH, I would prefer that application decisions like heap & port be made at the application level CMake and not at the kernel level CMake. This also has the advantage of a simpler path to a custom heap should one be desired. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the CMake you do not have access to configSUPPORT_DYNAMIC_ALLOCATION and configSUPPORT_STATIC_ALLOCATION (from FreeRTOSConfig.h), right? I made a PR to change the default behaviour of FREERTOS_HEAP , see #807 . (I was unaware that there were active pull requests attempting to address the same issue.). I would like to contribute to fix this issue. |
||||||||||||||||||||||||||||||
target_sources(freertos_kernel PRIVATE | ||||||||||||||||||||||||||||||
# If FREERTOS_HEAP is digit between 1 .. 5 - it is heap number, otherwise - it is path to custom heap source file | ||||||||||||||||||||||||||||||
$<IF:$<BOOL:$<FILTER:${FREERTOS_HEAP},EXCLUDE,^[1-5]$>>,${FREERTOS_HEAP},portable/MemMang/heap_${FREERTOS_HEAP}.c> | ||||||||||||||||||||||||||||||
) | ||||||||||||||||||||||||||||||
endif() | ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
target_link_libraries(freertos_kernel | ||||||||||||||||||||||||||||||
PUBLIC | ||||||||||||||||||||||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert back - improper use of CMake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why the usage of
CMAKE_CURRENT_LIST_DIR
is an improper use of CMAKE?The idea with this change is you no longer need to include the FreeRTOS-Kernel as a sub-directory, it can then be placed anywhere in your project as all of our cmake files aren't position dependent then. So instead of now where the kernel must be included in a sub-directory of your CMake File you would instead be able to include it from anywhere in your project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not that it is wrong, it is superfluous (not necessary) and is not required for what you were trying to achieve (The idea with this change...).
In any cmake project, one can
add_subdirectory(free_rtos_kernel_dir)
with the appropriate configuration beforehand and thatfree_rtos_kernel_dir
can be anywhere in your project. I'm not sure why you would do anything other than this? Could you please elaborate your use case?In recent changes - the CMakeFiles.txt of the various FreeRTOS components were updated to allow a very common way of importing libraries via CMake itself:
FetchContent
This will download the V10.6.1 version of the Freertos-Kernel into
build/_deps
And then run the CMake from a local build directory in
build/_deps
.To change the version - you then only change one line in the CMakeLists.txt that has the above example.
A great resource is Professional CMake for how to properly use the tool.