Incremental build fails when new syscall is added

[nordic-krch]

Describe the bug When using twister with --no-clean option it fails when new syscall is added between the builds. It seems that there are some cmake dependency issue that prevents regeneration of syscall header.

Please also mention any information which could help others to understand the problem you're facing:

• What target platform are you using?
• What have you tried to diagnose or workaround this issue?
• Is this a regression? If yes, have you been able to "git bisect" it to a specific commit?
• ...

To Reproduce Steps to reproduce the behavior:

1. git checkout ac3a6d3721 checkout a commit just before the commit which adds new syscall
2. scripts/twister -p nrf52840dk_nrf52840 -s samples/subsys/logging/logger/sample.logger.basic --no-clean
3. git checkout 1a0e8d6f9e checkout commit which adds new syscall
4. scripts/twister -p nrf52840dk_nrf52840 -s samples/subsys/logging/logger/sample.logger.basic --no-clean will fail due to syscall header not having a new call

Expected behavior Build should succeed because syscall files shall be re-generated.

Impact Cannot use --no-clean build in CI.

Additional context Following patch helps but I'm no CMake expert so hard to say if that is a proper solution:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 15671fc8ad..5d3b433483 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -793,7 +793,7 @@ add_custom_command(OUTPUT include/generated/syscall_dispatch.c ${syscall_list_h}
   ${SYSCALL_LONG_REGISTERS_ARG}
   ${SYSCALL_SPLIT_TIMEOUT_ARG}
   WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
-  DEPENDS ${PARSE_SYSCALLS_TARGET}
+  DEPENDS ${syscalls_json} ${struct_tags_json}
   )

[nashif]

This is not related to twister, this same issue can be reproduced with west and probably with cmake only, so it is a build system issue.

[nordic-krch]

yes, it's an issue with cmake dependencies just reproduced it in twister context.

[nordic-piks]

Any update about this issue? I got another reproduction of it - the same environment like @nordic-krch described - incremental builds. In my case, after such change https://github.com/zephyrproject-rtos/zephyr/commit/4b2bf5abccab6aefd6afe70f91000e21767b81a8 which should regenerate content of zephyr/include/generated/syscalls I got error:

zephyr/include/generated/syscalls/kernel.h:1333:19: error: conflicting types for 'k_pipe_put'; have 'int(struct k_pipe *, void *, size_t,  size_t *, size_t,  k_timeout_t)' {aka 'int(struct k_pipe *, void *, unsigned int,  unsigned int *, unsigned int,  k_timeout_t)'}
 1333 | static inline int k_pipe_put(struct k_pipe * pipe, void * data, size_t bytes_to_write, size_t * bytes_written, size_t min_xfer, k_timeout_t timeout)
      |                   ^~~~~~~~~~
zephyr/include/zephyr/kernel.h:4971:15: note: previous declaration of 'k_pipe_put' with type 'int(struct k_pipe *, const void *, size_t,  size_t *, size_t,  k_timeout_t)' {aka 'int(struct k_pipe *, const void *, unsigned int,  unsigned int *, unsigned int,  k_timeout_t)'}
 4971 | __syscall int k_pipe_put(struct k_pipe *pipe, const void *data,
      | 

Can solution proposed in this issue by nordic-krch be applied? Or there is another one needed?

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[TorstenRobitzki]

conflicting types for 'k_pipe_put'

I see the same issue. Conflicting declarations steams from a file that seems to be generated: build/mcuboot/zephyr/include/generated/syscalls/kernel.h:1333.

A make clean does not solve this. So it seems to me, that the clean target does not clean up all generated files.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.