Repository navigation
[FEATURE][Zephyr] Remove duplication of CMake rules between Zephyr and XTOS #8260
Description
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
Activity
kv2019i commentedon Sep 25, 2023
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.
lgirdwood commentedon Oct 2, 2023
@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.
lyakh commentedon Oct 26, 2023
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
marc-hb commentedon Oct 26, 2023
I noticed
sof/zephyr/CMakeLists.txtuseszephyr_sources(), not the plaintarget_sources(). I'm not sure why. I found these:zephyr/samples/**/CMakeLists.txtandzephyr/tests/**/CMakeLists.txtusetarget_sources().EDIT: there is some "documentation" in
zephyr/cmake/modules/extensions.cmakelgirdwood commentedon Oct 30, 2023
Can we drop target_sources everywhere and use zephyr sources e.g. somethimg like for xtos
marc-hb commentedon Oct 30, 2023
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.
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.cthat 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
*.cfiles could be shared in a CMake list and then added by aforeachloop. But again I think this would be the wrong thing to do.I agree this location is inconvenient. Let me think about it.
marc-hb commentedon Oct 31, 2023
I have something promising, stay tuned.
marc-hb commentedon Oct 31, 2023
Submitted
lgirdwood commentedon Nov 10, 2023
@marc-hb what do you think the next steps are now that #8422 is merged ?
marc-hb commentedon Nov 10, 2023
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.
cmake: a few new add_local_sources[_ifdef]() compatibility macros
196 remaining items
cmake/zephyr: unify cmake rules for src/trace
cmake/zephyr: unify cmake rules for src/logging
cmake/zephyr: unify cmake rules for src/samples
cmake/zephyr: unify cmake rules for src/probe
kv2019i commentedon Apr 2, 2025
Status update:
cmake/zephyr: unify cmake rules for src/lib
cmake/zephyr: unify cmake rules for src/library_manager
cmake/zephyr: unify cmake rules for src/trace
cmake/zephyr: unify cmake rules for src/logging
cmake/zephyr: unify cmake rules for src/samples
cmake/zephyr: unify cmake rules for src/probe
cmake/zephyr: unify cmake rules for src/idc
cmake/zephyr: unify cmake rules for src/idc
kv2019i commentedon Apr 4, 2025
With #9950 this issue is now closed.
The platform code rules are still in the sof/zephyr/CMakeLists.txt, but these should in the end disappear as we move to native Zephyr, so let's track this effort in #7248
Thanks for @marc-hb for doing the baseline work and coming up with the general approach how to do this!