feat(toolchain): Improved local setup

[Nick-Munnich]

Proof of concept of an idea to have a nicer local setup. See https://discord.com/channels/719497620560543766/1313518832434020384/1313518835055198371 for context.

For existing users wanting to try this out:

1. Checkout the branch
2. Place your zmk-config as a subdirectory of zmk, by cloning or otherwise. You should have zmk/zmk-config, with that naming.
3. Edit zmk/.west/config to point the manifest to zmk/local/west.yml:

[manifest]
path = local
file = west.yml

4. Run west update

You should now be able to build and flash as usual, using the zmk-config's config/west.yml to manage external modules, and with your zmk-config working fine for your own custom stuff, keymaps, etc. without the need to write -DZMK_EXTRA_MODULES etc for building.

Needs discussion, testing, and improved documentation.

TODO: Figure out a nicer interaction with our local west test and west manifest commands.

[urob]

I struggle a bit to see the value compared to what's already possible as of today. For example, here's an abridged version of the west.yml inside my zmk-config:

manifest:
  defaults:
    remote: urob
    revision: v0.1 # Pin everything to v0.1

  remotes:
    - name: zmkfirmware
      url-base: https://github.com/zmkfirmware
    - name: urob
      url-base: https://github.com/urob

  projects:
    # Upstream ZMK
    - name: zmk
      remote: zmkfirmware
      import: app/west.yml

    # ZMK modules
    - name: zmk-adaptive-key
      path: modules/zmk/adaptive-key
    - name: zmk-auto-layer
      path: modules/zmk/auto-layer
    - name: zmk-helpers
      path: modules/zmk/helpers
    - name: zmk-leader-key
      revision: v0.1+locality
      path: modules/zmk/leader-key
    - name: zmk-tri-state
      path: modules/zmk/tri-state

To set up my local workspace I just clone my repo and then initialize west and pull in all modules as usual:

west init -l config
west update
west zephyr-export

I can then build using west build without needing to specify any DZMK_EXTRA_MODULES. For example:

# run this from the root of your config repo
west build -s zmk/app -b <board> -DZMK_CONFIG=$(realpath config)

I like the current situation because:

• It allows the user to just maintain one config repo and one west.yml manifest
• No need for the user to explicitly clone or maintain ZMK
• It matches what GHA is already doing now, which makes results very predictable (and also requires only maintaining / catering to a single workflow)

---

Small side comment: In practice I use a small script that wraps west build and adds a few quality of life improvements:

• Parse build.yml so that just build <keyword> builds all board/shields in build.yml that match <keyword>
• Works from anywhere in the workspace (no need to be at the root of the repo)
• Automatically sets all options to west build so building is as easy as just build <keyword>
• Passes through additional options, e.g., just build <keyword> -p
• Copies the build artifacts to a default directory

I could see value in adding a custom west command to ZMK that does something similar to what I do in my just script.

[urob]

zephyrproject-rtos/west#725 might be relevant re: getting west commands to work