I don't understand west

[arv]

Hello,

I am trying to set the `BT_SHELL_NUS` project up as a standalone repository. My requirements for this are as follows: I only want to commit application code to git, not the entire zephyr sdk or nordic sdk. I do not want to fork the nordic sdk. I do not want to set environment variables. So I tried to use the west out of tree approach.

I have created a file structure that looks like this:

application/ - directory, includes a complete copy of the shell_bt_nus sample folder.
west.yml     - my west.yml file.

Then the west.yml file is set up as follows following the wiki:

manifest:
  remotes:
    - name: ncs
      url-base: https://github.com/nrfconnect
  defaults:
    remote: ncs
  projects:
    - name: nrf
      remote: ncs
      repo-path: sdk-nrf
      revision: v1.9.0
      import: true
  self:
    path: application

Now, when I run west init, west immediately clones the zephyr-rtos manifest repository instead of the one specified here. I have tried supplying this file on the command like --mf, and again the same issue occurs.

Finally, I have also tried placing the west.yml into application/ and then initializing with west init -l. This seems to get closest, and actually clones all of nrf, however, it then gets stuck on "recursive zephyr source" issues. In this case, I change the manifest slightly: self: path becomes "." instead of application. I am not sure if this is the right thing to do but it seems to make logical sense.

It appears I'm not the only one and someone opened an issue in upstream zephyr, see here: https://github.com/zephyrproject-rtos/zephyr/issues/35075 however I couldn't parse anything in this issue at all.

Can someone please correct whatever misunderstanding I have of west and how I am supposed to set up a west.yml such that I can west init/west update/west build from scratch? Just to reiterate the above, I'm not looking to clone the whole SDK and I would rather use west, for better or worse, than manage messy environment variable setups. IDEs are a no-go.

Specifically, the issue is that west is not treating my yaml file as something it should read in the layout I think is correct having read the nordic wiki. When I place the yml file in a subfolder it does actually follow it, but the resulting project is unbuildable due to recursive imports of zephyr (and I don't know why).

I'm a bit disappointed even a simple standalone sample doesn't appear to work.

Thanks.

[Charlie]

Hi Antony,

I assume you are following Workflow 4: Application as the manifest repository and develop under the Linux system. Can you confirm?

This workflow is quite similar to the current NCS(nRF Connect SDK), your project builds on top NCS/Zephyr, just like NCS(sdk-nrf) builds on top of Zephyr. You still cannot avoid managing messy environment variable setups like NCS does with manual installation on Linux. 

I suggest you set up an NCS development environment with nRF Connect for Desktop one-click installation on Windows or Mac(all the toolchain is configured automatically) and use VS code + nRF Connect Extention for your development. You can put your application project folder anywhere in the system, just add the folder to nRF Connect Extention when you need them. The whole process is quite smooth, even people without professional building environment knowledge can do it, so developers can focus on their own application.

Best regards,

Charlie

[arv]

Yes, I can confirm I'm trying to follow workflow 4, with a slightly non-trivial example (shell_bt_nus) to demonstrate that it correctly pulls in Nordic components. All code in application/ is taken from the nordic sdk and I'm following the west templates as on the wiki.

No IDEs or even browsers pretending to be IDEs, sorry. I'm after a scriptable command line build that can be fed into a CI pipeline at a later date: launching an IDE on a machine with no graphical console is obviously a no go. For what its worth, I am a professional developer, I have built with all kinds of gnarly makefiles. My Linux kernel is custom, I've written firmware for ppc, stm32, avr, I have all kinds of compilers on my system. I've also shipped software in Rust and Go, and in a past life I wrote Windows drivers people are, to my knowledge, still using in production. For a hobby project at some point I need to build the latest stable rust compiler for OpenBSD and I have a sneaking suspicion this will be easier to do than using your SDK.

I've also compiled for the nordic board using mynewt.

So I'm pretty comfortable with building stuff and I can't figure out how to combine your build with version control in any kind of sane way from 1-2 days of reading your wiki and trying to build the shell_bt_nus example this way. I gave up and posted here instead to see if I could get some help.

So what I really need is a set of instructions (ideally) or standalone example (ideally slightly more than LED blinking demonstrating a dependency on some nordic specific component, not just zephyr) I can use to understand the workflow 4 process and adapt this to my needs. It can be assumed arm-none-eabi-gcc is on the path (in this case, ARM's official compilers kept at their latest versions and these have been used to write firmware for other boards) as is west. My goal would be to type "west build" and have a firmware image compiled (or alternatively what ever the correct command line arguments to do that are), and then flash with nrfjprog.

Thanks!

[Charlie]

Hi Arv,

Can the CI solution for nRF9160: Asset Tracker v2 FW can satisfy your needs?

Firmware — nRF Asset Tracker 911cbddce975ab27b806dcae9c65630b36211fd2 documentation (nordicsemiconductor.github.io)

Best regards,

Charlie

[arv]

Hello,

I actually think I do understand now, yes. I think. What I'm trying to build is here: https://github.com/diagprov/firmware-demos/tree/master/nrf52-ncs-52840dk-bluetooth

There would be two ways to build this:

1. west init -m https://github.com/diagprov/firmware-demos/tree/master/nrf52-ncs-52840dk-bluetooth/firmware (I am not sure if west can cope with parts of git repositories like this, but ho hum).

2. clone the whole git, cd into nrf52-ncs-52840dk-bluetooth/firmware, west init --local, cd .., then use west normally.

So I think I understand how west expects to be laid out. I am not sure I _like_ it at all because it appears to be in conflict with how git repositories actually work, but, there's a lot of people who can't adapt to a non-subversion mental model.

I'm now onto the next set of problems: specifically, west build -b nrf52840dk_nrf52840 has the following complaint:

firmware-demos/nrf52-ncs-52840dk-bluetooth/firmware/src/main.c:23:33: error: 'CONFIG_BT_DEVICE_NAME' undeclared here (not
 in a function)
   23 | #define DEVICE_NAME             CONFIG_BT_DEVICE_NAME

but I guess this is another thread/discussion (this demo is entirely unmodified from the ncs tree, so basically it just doesn't work, but what's new).

I'll be honest, I think it may actually be easier simply to eschew west entirely, require the nordic tree to be checked out in a well known location and go from there. West seems to have a very opinionated, and frankly utterly wrong, understanding of git's capabilities. For example, here I was trying to start with a local git repository first and test before pushing up to github, but west wants to take over the cloning. Here are some things I suspect west totally cannot cope with:

• The fact my git repositories frequently contain multiple remotes. Some are to github, some not.
• The fact I may or may not monorepo, and west doesn't own the whole repository.
• The fact that branches can track remotes not all in the same repository if I want.

Thanks a lot!

Antony