nanopb compilation doesn't work

[nrbrook]

I am using zephyr_nanopb_sources to add some protobuf files to my app target, and this works fine in a normal build without mcuboot. However, when building with mcuboot it doesn't work. Here is the error I get:

Failed to import nanopb_pb2.py: type object 'FileOptions' has no attribute 'RegisterExtension'
Will automatically attempt to rebuild this.
Verify that python-protobuf and protoc versions match.
Using grpcio-tools protoc from /opt/nordic/ncs/toolchains/15b490767d/lib/python3.12/site-packages/grpc_tools/protoc.py
protoc builtin include path: ['/Users/nick/Documents/Repos/AirTurnWearable/application/build_rel_nrf52dk/application/src/proto/nanopb/generator/proto', '/opt/nordic/ncs/toolchains/15b490767d/lib/python3.12/site-packages/grpc_tools/_proto']
Python version 3.12.4 (main, Jun  7 2024, 04:28:19) [Clang 14.0.0 (clang-1400.0.29.202)]
Using python-protobuf from /opt/nordic/ncs/toolchains/15b490767d/lib/python3.12/site-packages/google/protobuf/__init__.py
Python-protobuf version: 5.27.1

This appears to be related to this issue: https://github.com/zephyrproject-rtos/zephyr/issues/72265

What's strange is that running the command that fails from a nRF toolchain terminal succeeds. So it appears something about the mcuboot build environment is causing the failure.

I'm using toolchain and SDK 2.8.0

[Amanda Hsieh]

Hi, 

I can reproduce the issue with zephyr/samples/modules/nanopb. Let me check with the team and then back to you. 

Regards,
Amanda H.

[nrbrook]

Hi, did you find anything out from the team? I can report as a bug on zephyr, but it would be good to have a workaround.

Thanks

[nrbrook]

The nanopb sample does build correctly in VS Code, yes, but the release build in nRF Desktop application does not (when I've added `zephyr_nanopb_sources`). Presumably it builds differently (using west?).

[Amanda Hsieh]

The release build would use prj_release.conf under the nrf_desktop/configuration/*board_name. Maybe you can compare the .config file under build/nrf_desktop/zephyr from the release/ debug build to see what is missing. 

[nrbrook]

I looked at those, they were the same. So I deleted all _release suffix files in the board configuration directory, and it still didn't build. So I removed all .obj, .a, .h files from the debug build dir, then compared the two build dirs. I saw that the release build CMakeCache.txt file was missing 

//No help, variable specified on the command line.
NCS_TOOLCHAIN_VERSION:UNINITIALIZED=NONE

I added that, and it built... And now when I remove it, it is immediately added back again when building. I have no idea how to break it again. I will keep going, hopefully this works well enough now. I'll mark as resolved in a few days if so.

[nrbrook]

Amanda Hsieh I also need to build using west for deployment, is there a way to get this working with west?

[Amanda Hsieh]

I have reported to the team. Before working with west, please use VS Code as the workaround. Sorry for the inconvenience. 

[nrbrook]

The issue stems from NcsConfig.cmake setting the protoc executable path to the toolchain's protoc. When running from VS Code, NCS_TOOLCHAIN_VERSION is NONE and the protoc path is not set. I'm not sure what an appropriate fix would be, but a workaround is to modify <sdk root>/nrf/share/ncs-package/cmake/NcsConfig.cmake line 61, insert 

set(NCS_TOOLCHAIN_PROTOC ${NCS_DIR}/modules/lib/nanopb/generator/protoc)

I've not managed to find a workaround which does not require this file modifying, because it appears that the rest of the package discovery is required when using a toolchain profile terminal.

[Amanda Hsieh]

It's fixed by https://github.com/nrfconnect/sdk-nrf/pull/19225

[nrbrook]

It still isn't fixed on my system with SDK 3.0.0, out the box on macOS.

The issue now stems from the way the terminal profile is being set up by the nRF Connect VS Code extension.

My PATH is normally <list of paths> after opening a normal macOS terminal. When opening a normal VS Code terminal PATH contains duplicates, but if I set "terminal.integrated.inheritEnv": false it doesn't. But either way, after opening an NCS terminal profile, PATH has been set to <list of paths>:<toolchain dirs>:<list of paths>. For some reason the paths are duplicated and the toolchain dirs are not at the front.

Running PATH=/opt/nordic/ncs/toolchains/ef4fc6722e/opt/bin:$PATH works around it.