casaroli commented on code in PR #3673: URL: https://github.com/apache/nuttx-apps/pull/3673#discussion_r3699853123
########## system/libuv/Makefile: ########## @@ -144,7 +144,15 @@ CSRCS += runner.c CSRCS += runner-unix.c CSRCS += echo-server.c -CSRCS += $(wildcard libuv/test/test-*.c) +# test-fork.c and test-pipe-close-stdout-read-stdin.c call fork(). Every +# test they define is already excluded from the task list on NuttX by +# 0001-libuv-port-for-nuttx.patch, so they are dead code here. Review Comment: Done — both the Makefile and `CMakeLists.txt` now drop the two files only when `CONFIG_ARCH_HAVE_FORK` is unset, so on every architecture today they are built exactly as before. On the first question, though: keeping them where the arch supports `fork()` does not actually recover any coverage, because the exclusion is not keyed on fork availability. `0001-libuv-port-for-nuttx.patch` widens the two `#ifndef _WIN32` guards in `test/test-list.h` to `#if !defined(_WIN32) && !defined(__NuttX__)`, and those guards cover the complete set of tests the two files define — all nine `fork_*` entries (`fork_timer`, `fork_socketpair`, `fork_socketpair_started`, `fork_signal_to_child`, `fork_signal_to_child_closed`, `fork_fs_events_child`, `fork_fs_events_child_dir`, `fork_fs_events_file_parent_child`, `fork_threadpool_queue_work_simple`) plus `pipe_close_stdout_read_stdin`. On NuttX they compile and link but are never entered. I have taken the suggestion anyway, because gating is the better shape for two reasons that do not depend on that argument: it keeps this PR a strict no-op on master rather than nearly one, and it matches what `testing/ltp` does a few lines away instead of asking the reader to accept a claim about a vendored patch. Verified on `sim:citest` under Linux GCC, building the same tree twice against a NuttX with and without the symbol: with `CONFIG_ARCH_HAVE_FORK=y` 170 libuv test files are compiled including both of these, and with it unset 168 are compiled and these two are the only ones missing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
