thesofproject
audio/CMakeLists.txt: move testbench/plugin to new, separate file
Pure cleanup to prepare de-duplication #8260, zero functional change.
2 commits, the main one:
Commit https://github.com/thesofproject/sof/commit/7680a7b0dcea3967f3dcbc88edc993cc445f701c ("cmake: add testbench host build") added a
return() in the middle of src/audio/CMakeLists.txt to exclude some
C files from testbench compilation.
It wasn't easy to read already at the time. Now that the file has grown bigger it's become even harder to spot and even more confusing.
Soon, https://github.com/thesofproject/sof/issues/8260 will also add Zephyr to this file which will make things much worse.
Solve all this by moving testbench and plugin compilation to a new,
separate, native.cmake file.
Reported in https://github.com/thesofproject/sof/issues/8606
CAVS https://sof-ci.01.org/sofpr/PR8892/build3030/devicetest/index.html and ACE https://sof-ci.01.org/sofpr/PR8892/build3029/devicetest/index.html are both 100% green!
@lrudyX , @wszypelt I'm afraid we need your help yet again.
All tests fail with "no such file or directory" in build number https://sof-ci.01.org/sof-pr-viewer/#/build/PR8892/build13653253
13:40:38,154 INFO - _ ERROR at setup of TestPipelinesStates.test_00_14_host_loop_pipeline_set_states_stress[PipelineSetState] _
13:40:38,155 INFO - [gw0] win32 -- Python 3.12.1 C:\Python312\python.exe
13:40:38,155 INFO - cavs_scripts-py\tests\avs\conftest.py:524: in load_fw_with_cleanup
13:40:38,155 INFO - with prepare_fnc(
13:40:38,155 INFO - C:\Python312\Lib\contextlib.py:137: in __enter__
13:40:38,155 INFO - return next(self.gen)
13:40:38,155 INFO - cavs_scripts-py\tests\avs\conftest.py:301: in dsp_test_prepared
13:40:38,156 INFO - test_controller.env_init(
13:40:38,156 INFO - cavs_scripts-py\utilities\test_controller.py:260: in env_init
13:40:38,156 INFO - self._fw_manager.read_fw_binary(get_fw())
13:40:38,156 INFO - cavs_scripts-py\utilities\fw_manager.py:445: in read_fw_binary
13:40:38,156 INFO - with self.binary_to_file(fw_data) as (fw_file, fw_name):
13:40:38,157 INFO - C:\Python312\Lib\contextlib.py:137: in __enter__
13:40:38,157 INFO - return next(self.gen)
13:40:38,157 INFO - cavs_scripts-py\utilities\fw_manager.py:425: in binary_to_file
13:40:38,157 INFO - handle, handle_name = open(fw_data, "rb"), str(fw_data) # noqa: SIM115 --TODO
13:40:38,157 INFO - E FileNotFoundError: [Errno 2] No such file or directory:
'C:\\Testing\\Builds\\pull-8892-merge_2027770\\cSOF_zephyr\\LNL\\
build-sof-staging\\sof\\community\\sof-lnl.ri'
Same failures with sof-mtl.ri and sof-tgl.ri. I have not found anything suspicious in the build logs.
This can't possibly be related to this PR.
@marc-hb Slowly, QB is getting back on track. After checking the build once again, FW building and tests in the Internal Intel CI system turn green
Newer https://sof-ci.01.org/sof-pr-viewer/#/build/PR8892/build13655958 is green - thanks!
"native" could be a bit ambiguous, lets spell out plugin.cmake and have a comment here that says this is to build plugin, testbench etc.
I naively trusted the Kconfig help added for COMP_MODULE_SHARED_LIBRARY_BUILD in commit b720f1a73315 (ALSA plugin PR #8132), it says:
Select if you want to build modules as shared objects that can be used to run pipelines on the host with the testbench or the ALSA plugin. (emphasis mine).
But after testing a bit more I just realized that this recent COMP_MODULE_SHARED_LIBRARY_BUILD is not used by the testbench at all...? Can someone explain? @singalsu maybe?
I also remembered that the testbench supports both "native" and non-native code. Neither uses COMP_MODULE_SHARED_LIBRARY_BUILD
scripts/rebuild-testbench.sh -h
usage: scripts/rebuild-testbench.sh [-f] [-p <platform>]
-p Build testbench binary for xt-run for selected platform, e.g. -p tgl
When omitted, perform a BUILD_TYPE=native, compile-only check.
The mystery deepens...
More context than anyone wants:
"native" is the non-negative term used by Zephyr to say "not compiled for the product": https://docs.zephyrproject.org/latest/boards/posix/native_sim/doc/index.html https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/index.html https://docs.zephyrproject.org/latest/samples/drivers/uart/native_tty/README.html
"module", "shared" and "library" are all ambiguous now that we have shared "modules" / "libraries" running on DSP hardware too:
- https://docs.zephyrproject.org/latest/services/llext/index.html
- https://github.com/thesofproject/sof/pull/8828
"host" can be quite ambiguous too:
- https://mesonbuild.com/Cross-compilation.html
- https://github.com/thesofproject/sof/pull/8132#pullrequestreview-1604934599
"native" could be a bit ambiguous, lets spell out plugin.cmake and have a comment here that says this is to build plugin, testbench etc.
I naively trusted the Kconfig help added for
COMP_MODULE_SHARED_LIBRARY_BUILDin commit b720f1a (ALSA plugin PR #8132), it says:
Lets just say any make target that does not run on the DSP can have a Cmake.plugin Cmake.testbench etc.. Need to be quick if this is for v2.9
