Infinite build loop with some examples, dirty build.ninja

Report bugs
#1

Question/Issue:
With multiple attempted deployments from Edge Impulse, I keep getting a build loop ultimately failing due to a dirty build.ninja file. I’ve checked system datetime, pristine builds, restarting my computer, etc.
Project ID:
Various, but at the current moment is project 353426.
Context/Use case:
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...

…about 95 more of these…

[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.

#2

Hi @anyland,

Could you provide more context around this project:

  1. Where are you seeing these error messages? On your local computer or on the Edge Impulse Studio?
  2. If local, what target are you trying to build for and what toolchain are you using?
  3. If on Edge Impulse Studio, how did you get these errors to appear? Are you trying to build a deployment for a particular target?
#3
  1. They are in the build console of VS Code, on my local computer.
  2. Building with nRF for an nRF52840dk, flashing is not an issue as building hasn’t succeeded yet.
  3. I have set the target the same on Edge Impulse.

The weird part is this issue is only appearing if I attempt to build/deploy models (via the Edge Impulse Wrapper sample provided with nRF) that are computer vision based - the Continuous Motion model works just fine. Thanks for any help.

#4

@anyland
What time zone are you located in?

Kind regards,
Mateusz

#5

Mountain time, USA. [insert more characters]

#6

@anyland
Could you try to ‘touch’ all files in your project directory?

find . -type f -exec touch {} +

I saw a similar situation once, but as no one could reproduce it, I blamed the set of apps (CMake, ninja, etc.) on my computer.

Kind regards,
Mateusz

#7

Tried that but it didn’t seem to work. We’re not sure, it’s not a reliable issue.

We’ve started getting this error:

CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/ExternalProject.cmake:3195 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.

Wondering if it could possibly be a cause, but our CMakeLists.txt also specifies a remote file to download so that could be where that comes from instead.

#8

Hi @anyland
This is a warning. Is it a reason for the failed build? If yes, then proceed as the message suggests.

Kind regards,
Mateusz

#9

I know it’s a warning. I’m not sure if it’s the reason for the failed build.