Update nrf example dependencies

[jamessizeland]

Its been a while since I've been able to look at this project, but I thought I'd have a go at updating the dependencies on the nrf example as they look quite far behind. I ended up in a dependency knot, so I just wanted to put this here to see if anyone has any ideas about what the blockers are to this update?

(I was getting odd dependency mismatch errors with nrf-sdc saying it wanted 0.7.0 and 0.8.0, but everything there seemed to point unambiguously to 0.8.0.)

[finalyards]

Do you have that work as a fork/branch? Can have a look (though don't have hw).

[finalyards]

Regarding nrf-sdc, I've noticed that pulling it takes considerable time, and disk space.

$ du -h -d1 ~/.cargo/git/checkouts
[...]
4.2G	/home/ubuntu/.cargo/git/checkouts/nrf-sdc-60aaf678d91c8332

I can reduce that to ~370MB by treating it as a git submodule, instead.

There is a proof of this in the #474 PR. It does come with some caviats:

• all use of nrf-sdc would be to the same revision (this may be a benefit)
• the users need to run a single git submodule update --init ... command, when starting to work with the repo

I think the benefits are great, though. Faster initial downloads, way less disk use - which radiates to the CI problems that are expressed elsewhere.

Would the project be interested in testing this submodule solution?

Analysis:

The core reason is that cargo git references don't do shallow clones - they pull the whole history of each repo - and its submodules, which are three in the case of nrf-sdc. This causes the 4.2GB mass.

[HaoboGu]

I think this is a nrf-sdc issue, not trouble's

[finalyards]

I think this is a nrf-sdc issue, not trouble's

Why do you think that?

It's always good to explain your thoughts. Otherwise it's your thoughts against mine - with enough details, we can have the matters arguing, not the people.

---

This takes two separate versions of nrf-sdc into use. That's... weird in my opinion, but not the problem.

I cleared my cargo caches (on my VM) and run the full CI builds. Let's see what happens...

    Updating git submodule `https://github.com/ARM-software/CMSIS_5.git`
       Fetch [==>                      ]  13.51%, 5.62MiB/s        

    Updating git submodule `https://github.com/NordicSemiconductor/nrfx.git`
       Fetch [===================>     ]  80.07%, (5065/6646) resolving deltas  

    Updating git submodule `https://github.com/nrfconnect/sdk-nrfxlib.git`
       Fetch [=>                       ]   9.66%, 6.96MiB/s        

It takes more than 3 minutes for these three dependencies to download, which has definitely caught my eye, working with the repo.

Sure. nrf-sdc could fix this by making their side submodules clone shallow. But I don't really wish to dive that deep. Once trouble uses nrf-sdc from crates.io, this is no longer our problem. Currently, because of the above 3 minutes, and the disk space usage, I feel it to be.

Apropos, the disk size. Let's see:

$ du -h -d2 ~/.cargo/
544K	/home/ubuntu/.cargo/git/db
1.1G	/home/ubuntu/.cargo/git/checkouts
1.1G	/home/ubuntu/.cargo/git
21M	/home/ubuntu/.cargo/registry/index
31M	/home/ubuntu/.cargo/registry/cache
228M	/home/ubuntu/.cargo/registry/src
279M	/home/ubuntu/.cargo/registry
91M	/home/ubuntu/.cargo/bin
1.5G	/home/ubuntu/.cargo/

The 1.1GB comes directly from a deep-clone of nrf-sdc, and its submodules.

Part of the problem is that these downloads pile up, also in the GitHub Actions cache. Whenever the nrf-sdc revision is changed, also the previous ones remain in the cache. And 4GB caches are not a good thing (currently at 2.9GB). At the least, they are unnecessary.

@HaoboGu Your short answer made me feel that raising this is not important, and a change is not needed. I think (pun!) that this issue deserves a discussion.

One important note: None of this matters, once the nrf-sdc dependency comes via crates.io. It currently doesn't, and I'm just asking whether the project would be interested in a change that reduces the download/disk/time consumption.

---

p.s. The "3min" was on my developer VM, but let's see how long it takes the CI Action to clone the said repo. source

1min 22 secs

Sat, 29 Nov 2025 16:02:22 GMT
    Updating git submodule `[https://github.com/ARM-software/CMSIS_5.git`](https://github.com/ARM-software/CMSIS_5.git%60)
Sat, 29 Nov 2025 16:02:33 GMT
From https://github.com/ARM-software/CMSIS_5
Sat, 29 Nov 2025 16:02:33 GMT
 * [new ref]           51f8f89612c8330c0116479cfe3a2cb04c390e2b -> refs/commit/51f8f89612c8330c0116479cfe3a2cb04c390e2b
Sat, 29 Nov 2025 16:02:34 GMT
    Updating git submodule `[https://github.com/NordicSemiconductor/nrfx.git`](https://github.com/NordicSemiconductor/nrfx.git%60)
Sat, 29 Nov 2025 16:02:40 GMT
From https://github.com/NordicSemiconductor/nrfx
Sat, 29 Nov 2025 16:02:40 GMT
 * [new ref]         11f57e578c7feea13f21c79ea0efab2630ac68c7 -> refs/commit/11f57e578c7feea13f21c79ea0efab2630ac68c7
Sat, 29 Nov 2025 16:02:41 GMT
    Updating git submodule `[https://github.com/nrfconnect/sdk-nrfxlib.git`](https://github.com/nrfconnect/sdk-nrfxlib.git%60)
Sat, 29 Nov 2025 16:02:59 GMT
From https://github.com/nrfconnect/sdk-nrfxlib
Sat, 29 Nov 2025 16:02:59 GMT
 * [new ref]             3b210a24d3bc7ecfc268e0feab6436306b11e7cb -> refs/commit/3b210a24d3bc7ecfc268e0feab6436306b11e7cb
Sat, 29 Nov 2025 16:03:01 GMT
    Updating git submodule `[https://github.com/ARM-software/CMSIS_5.git`](https://github.com/ARM-software/CMSIS_5.git%60)
Sat, 29 Nov 2025 16:03:13 GMT
From https://github.com/ARM-software/CMSIS_5
Sat, 29 Nov 2025 16:03:13 GMT
 * [new ref]           51f8f89612c8330c0116479cfe3a2cb04c390e2b -> refs/commit/51f8f89612c8330c0116479cfe3a2cb04c390e2b
Sat, 29 Nov 2025 16:03:13 GMT
    Updating git submodule `[https://github.com/NordicSemiconductor/nrfx.git`](https://github.com/NordicSemiconductor/nrfx.git%60)
Sat, 29 Nov 2025 16:03:20 GMT
From https://github.com/NordicSemiconductor/nrfx
Sat, 29 Nov 2025 16:03:20 GMT
 * [new ref]         11f57e578c7feea13f21c79ea0efab2630ac68c7 -> refs/commit/11f57e578c7feea13f21c79ea0efab2630ac68c7
Sat, 29 Nov 2025 16:03:21 GMT
    Updating git submodule `[https://github.com/nrfconnect/sdk-nrfxlib.git`](https://github.com/nrfconnect/sdk-nrfxlib.git%60)
Sat, 29 Nov 2025 16:03:39 GMT
From https://github.com/nrfconnect/sdk-nrfxlib
Sat, 29 Nov 2025 16:03:39 GMT
 * [new ref]             3b210a24d3bc7ecfc268e0feab6436306b11e7cb -> refs/commit/3b210a24d3bc7ecfc268e0feab6436306b11e7cb
Sat, 29 Nov 2025 16:03:44 GMT
   Compiling trouble-host-macros v0.3.0 (/home/runner/work/trouble/trouble/host-macros)

[HaoboGu]

@HaoboGu Your short answer made me feel that raising this is not important, and a change is not needed. I think (pun!) that this issue deserves a discussion.

Sorry for not making it clear, it definitely deserves some discussion, but I prefer to solve the 'root cause' in nrf-sdc, not just add a workaround in trouble repo.

For the solution: I think adding a submodule in trouble repo is not a good way -- you cannot reuse the cache in .cargo, everytime you switch branches with different nrf-sdc version, you have to redownload the nrf-sdc repo again.

This issue also happens even if we use the crates.io version, that's why I think solving it in nrf-sdc is better: not only ci benefits from it, the daily development and all downstream users benefit from it too.