app_smem: Correct missing dependency for linker script generation
The app_smem linker script files were being generated by a python
script based on the contents of the cmake-generated
compile_commands.json file. But it forgot to include a dependency on
the input. It also has the misfeature of being generated at cmake
interpretation time with a real but empty stub.
This worked for quite a while, because the dependency on "kernel"
(it's not clear to me why this was there but I'm not brave enough to
remove it) forced the file to rebuild any time any of the C code in
the system changed, which was almost always guaranteed.
But then commit 0224f2c508
("device.h:
rework the device_extern.h mechanism") came along and removed a
generated include from device.h and saved a bunch of build time. And
it also meant that no kernel code was being compiled anymore. So now,
a second build picked up that empty stub file and failed with linker
warnings about the orphan sections that didn't find a place in the
link.
But second builds after cmake re-invocations are an obscure edge case,
right? Well, no. It turns out that this is exactly what "twister -f"
does in CI, in order to get retries for test cases that fail
spuriously (mostly for unavoidable host timer-related glitches on SMP
platforms).
So the end result was that this problem showed itself as a silent
failure of the retry mechanism in twister/CI, making it look for all
the world like the timer tests had all suddenly gone flaky.
Fun times.
Signed-off-by: Andy Ross <andyross@google.com>
This commit is contained in:
parent
a41f4f30b5
commit
6cfb18686e
|
@ -922,6 +922,7 @@ if(CONFIG_USERSPACE)
|
|||
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
|
||||
DEPENDS
|
||||
kernel
|
||||
${CMAKE_BINARY_DIR}/compile_commands.json
|
||||
${ZEPHYR_LIBS_PROPERTY}
|
||||
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/
|
||||
COMMAND_EXPAND_LISTS
|
||||
|
|
Loading…
Reference in a new issue