Support use cases other than Zephyr RTOS

West can be already used for other purposes than Zephyr development, even without sacrificing the parts of it that make it convenient for Zephyr.

This issue tracks first-class support for that.

The main issue I’m aware of is an error about a missing zephyr base, which appears if you have a manifest without a zephyr project, and is annoying but can be safely ignored

For now, to work around this, run something like:

west config zephyr.base shut-up-shut-up

The error is:

ERROR: no --zephyr-base given, ZEPHYR_BASE is unset, west config contains no zephyr.base setting, and no manifest project has path "zephyr"

It would be nice to generalize the existing mechanism for setting configuration variables based on the contents of the manifest so you could do something like this:

manifest:
  self:
    path: zephyr
    config-vars:
      - zephyr.base: {abspath}

Where the config-vars key in the manifest’s self subsection (or any project element) would be a list of config_variable: value pairs, where each value is a format string like that passable to west list --format. These values would be set at west update time, as if with west config --local config_variable $(west list --format="value" path_to_project), provided that they do not already have values.

With that, we could move the ZEPHYR_BASE environment setting down into each of the zephyr-specific extension commands, or do some other reasonable thing if we want to keep it inside west, and get rid of the error (and the zephyr-specific error).

[mbolivar]

The idea would be to host its documentation on readthedocs instead. But that will take quite some doing. We want the code to be ready before we try to do that.

[bengartner]

I updated to the master instead of the 0.5.8, and it seems like both these issues are resolved. Possibly as a side-effect of removing bootstrapping. So probably no reason to clean track these unless someone sees them in 0.6.0+.