Infinite build loop with some examples, dirty build.ninja

[alnyland]

With multiple of the provided samples with the SDK, I'm getting a repeated build loop that ultimately fails due to a remaining "dirty build.ninja". This is primarily with some Edge Impulse samples, so I've posted there as well, but these samples are provided in the nRF SDK.

The build output is as follows, from the Wrapper sample using a custom replication of the FOMO sample:

[143/158] No update step for 'edge_impulse_project'
[144/158] Performing patch step for 'edge_impulse_project'
[145/158] Performing configure step for 'edge_impulse_project'
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/nordic/ncs/toolchains/20d68df7e5/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build/edge_impulse/src/edge_impulse_project-build
[145/158] Performing build step for 'edge_impulse_project'
[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build/edge_impulse/src/edge_impulse_project-build
[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build/edge_impulse/src/edge_impulse_project-build
[0/1] Re-running CMake...

....

[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build/edge_impulse/src/edge_impulse_project-build
ninja: error: manifest 'build.ninja' still dirty after 100 tries

FAILED: edge_impulse/src/edge_impulse_project-stamp/edge_impulse_project-build edge_impulse/src/edge_impulse_project-build/libedge_impulse.a 
cd /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build/edge_impulse/src/edge_impulse_project-build && /opt/nordic/ncs/toolchains/20d68df7e5/Cellar/cmake/3.20.5/bin/cmake --build .
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /opt/nordic/ncs/toolchains/20d68df7e5/bin/cmake --build /opt/nordic/ncs/v2.5.2/nrf/samples/edge_impulse/wrapper_2/build


If anyone has seen this before or has a guess of how to fix it, that'd be greatly appreciated.

[alnyland]

The issue ended up being from a compile time error that was hidden in the print statements most of the time I tried.

/opt/nordic/ncs/v2.5.2/nrf/lib/edge_impulse/ei_wrapper.cpp: At global scope:

/opt/nordic/ncs/v2.5.2/nrf/lib/edge_impulse/ei_wrapper.cpp:56:31: error: static assertion failed

   56 | BUILD_ASSERT(DATA_BUFFER_SIZE > INPUT_WINDOW_SIZE);

/opt/nordic/ncs/v2.5.2/zephyr/include/zephyr/toolchain/gcc.h:70:50: note: in definition of macro 'BUILD_ASSERT'

   70 | #define BUILD_ASSERT(EXPR, MSG...) static_assert(EXPR, "" MSG)

      |                                                  ^~~~

/opt/nordic/ncs/v2.5.2/nrf/lib/edge_impulse/ei_wrapper.cpp:56:31: note: the comparison reduces to '(2500 > 9216)'

   56 | BUILD_ASSERT(DATA_BUFFER_SIZE > INPUT_WINDOW_SIZE);

/opt/nordic/ncs/v2.5.2/zephyr/include/zephyr/toolchain/gcc.h:70:50: note: in definition of macro 'BUILD_ASSERT'

   70 | #define BUILD_ASSERT(EXPR, MSG...) static_assert(EXPR, "" MSG)

      |                                                  ^~~~

ninja: build stopped: subcommand failed.

By adding CONFIG_EI_WRAPPER_DATA_BUF_SIZE=[bigger size] to the prj.conf I was able to fix this issue.

Edit (an hour later): This only fixed it for the one project, the Continuous Motion project that was working before is not working currently.

[Th2001]

Thanks alnyland, I've just encountered this issue today 

[alnyland]

Glad to hear, I honestly forgot that I'd put a conclusion to this issue. I'll go ahead and mark it as solved, hopefully that allows it to stay around for others to look at when needed. 

This issue was so weird, it was I guess a compile time error that was shown to the developer as a very different issue. And it doesn't help when there are multiple layers of build systems.