[FEATURE][Zephyr] Remove duplication of CMake rules between Zephyr and XTOS

[kv2019i]

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

• [FEATURE][Zephyr] Clarify expectations of platform.h for Zephyr SOF builds #7248
• [FEATURE] remove duplicated C files additions in CMake rules for src/audio/ modules #8606

[kv2019i]

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]

@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]

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]

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:

• cmake: Use plain CMake instead of Zephyr's custom interface zephyrproject-rtos/zephyr#8439
• Best practice for "external libraries" and cmake zephyrproject-rtos/zephyr#43650

zephyr/samples/**/CMakeLists.txt and zephyr/tests/**/CMakeLists.txt use target_sources().

EDIT: there is some "documentation" in zephyr/cmake/modules/extensions.cmake

[lgirdwood]

Can we drop target_sources everywhere and use zephyr sources e.g. somethimg like for xtos

#define zephyr_sources(x) target_sources(x)

[marc-hb]

#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.

[marc-hb]

I agree this location is inconvenient. Let me think about it.

I have something promising, stay tuned.

[marc-hb]

Submitted

• Start decentralizing zephyr/CMakeLists.txt #8422

[lgirdwood]

@marc-hb what do you think the next steps are now that #8422 is merged ?

[marc-hb]

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.

[kv2019i]

This is well under way, but I think completing the task will go beyond SOF2.8, bumping milestone.

[marc-hb]

This is still high on my list but unlikely to happen for v2.9

[lgirdwood]

This is still high on my list but unlikely to happen for v2.9

We can do this incrementally, module by module if needed.

[marc-hb]

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.

[kv2019i]

Stable-v2.9 branched, this didn't make the cut, bumping to 2.10.

[kv2019i]

No owner, moving to v2.12

[marc-hb]

#8892 should still work

[kv2019i]

Feature cutoff for v2.12, moving this to v2.13.

[lgirdwood]

@kv2019i one for your planning.