thesofproject
[FEATURE][Zephyr] Remove duplication of CMake rules between Zephyr and XTOS
Is your feature request related to a problem? Please describe. When a software module is added to SOF that can be used both in XTOs and in Zephyr builds, the module sources need to be added to CMake rules twice:
- first in sof/src/foo/CMakeLists.txt (for XTOS), and
- second time to sof/zephyr/CMakeLists.txt (for Zephyr)
This split of Cmake rules dates back to the time when Zephyr support was introduced and codebase was not cleanly split between operating systems. Now we have a cleaner split at top-level source directories, so it should be possible to start cleaning up this overlap in definitions.
Describe the solution you'd like
Describe alternatives you've considered
Additional context Platforms where transition to Zephyr is still in progress might cause some extra challenges to doing this makefile cleanup. E.g. see XTOS-only a
- https://github.com/thesofproject/sof/issues/7248
- #8606
FYI @dbaluta @lgirdwood @marc-hb @marcinszkudlinski -- not tagging to v2.8 yet. A bit more feasibility and work effort analysis is needed to gauge the effort and options. But sooner or later we need to get rid of the duplication.
@kv2019i I'm going to track this for v2.8, even if its likely to complet in v2.9. Just to keep it on our radar.
the best would be of course if we could re-use CMakeLists.txt in subdirectories for both XTOS and Zephyr. If this is impossible, we could move XTOS specific code to xtos.cmake, add Zephyr to zephyr.cmake and put any common code in CMakeLists.txt
if we could re-use CMakeLists.txt in subdirectories for both XTOS and Zephyr.
I noticed sof/zephyr/CMakeLists.txt uses zephyr_sources(), not the plain target_sources(). I'm not sure why. I found these:
- https://github.com/zephyrproject-rtos/zephyr/issues/8439
- https://github.com/zephyrproject-rtos/zephyr/discussions/43650
zephyr/samples/**/CMakeLists.txt and zephyr/tests/**/CMakeLists.txt use target_sources().
EDIT: there is some "documentation" in zephyr/cmake/modules/extensions.cmake
Can we drop target_sources everywhere and use zephyr sources e.g. somethimg like for xtos
#define zephyr_sources(x) target_sources(x)
#define zephyr_sources(x) target_sources(x)
Not without first understanding the difference between the two... even then, that would be super confusing considering Zephyr itself uses both. CMake is painful enough and short-staffed enough already.
When a software module is added to SOF that can be used both in XTOS and in Zephyr builds, the module sources need to be added to CMake rules twice:
I think this is a feature, not a bug. Pretty much every SOF engineer I've seen is either working with Zephyr or with XTOS but never with both. So, any engineer adding a new .c file will most likely have tested the new file in ONLY one of these environments (if tested at all, see for instance smart_amp.c that never compiled #8411). So why should they (accidentally?) add the new .c file to the other, totally untested environment? If another engineer wants to re-use the new .c file in the other environment then they can add it there after testing it.
All this being said, the list of common *.c files could be shared in a CMake list and then added by a foreach loop. But again I think this would be the wrong thing to do.
second time to sof/zephyr/CMakeLists.txt (for Zephyr)
I agree this location is inconvenient. Let me think about it.
I agree this location is inconvenient. Let me think about it.
I have something promising, stay tuned.
My plan is to wait ~1 week for the sky to fall (e.g: people compiling SOF in some unusual Zephyr configurations) and if that has not happened then just keep at it: moving more and more files gradually. It should only take a few shots.
This is well under way, but I think completing the task will go beyond SOF2.8, bumping milestone.
This is still high on my list but unlikely to happen for v2.9
We can do this incrementally, module by module if needed.
This is still high on my list but unlikely to happen for v2.9
Very bad phrasing sorry, I meant unlikely to be completed for v2.9. I will hopefully have time to make some progress before v2.9.