Support 4th level west -c config.ini file(s)

[pabigot]

In September 2025, the title was changed by @marc-hb from the original
"add environment support for defaulting arguments"
to:
"Support 4th level west -c config.ini file(s)"

---

Add environment support for defaulting arguments.

It would be wonderfully cool if west had a facility to infer defaults from environment variables.

I tend to build on a variety of boards. If I could do:

WEST_BUILD_BOARD=pca10056

and then have:

rm -rf build && west build

automatically infer --board pca10056 things would be easier.

Similarly I always sign with:

WEST_SIGN_KEY=${HOME}/.sensitive/pab-mcuboot.pem

It would be nice to avoid the extra arguments of:

west sign --key ${HOME}/.sensitive/pab-mcuboot.pem

or (from zephyrproject-rtos/zephyr#27688) have to use:

west build ... -- -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"${HOME}/.sensitive/pab-mcuboot.pem\"

It's fairly common that I run the same sequence of commands on different boards to test them or assess why they're different. Having board-specific arguments complicates reproducing builds on different platforms. Taking parameters from the environment would allow me to have multiple shell windows, one for each board, with the commands (held in an editor buffer) being portable between them.

The variable name proposed here is WEST_<command>_<long-option> which seems automatable. Alternatively support an INI file that held defaults and could be selected by a single new global parameter that specified where to read them.

cc:

• Support dropin config files (within .d directories) #849
• [alternative] Support multiple west config files per config level #867
• xtensa-build-zephyr: pure comment/link to west config simplification thesofproject/sof#10307

[mbolivar-nordic]

I agree this would be a worthwhile enhancement.

Alternatively support an INI file that held defaults and could be selected by a single new global parameter that specified where to read them.

This would be my preference, due to a slight personal allergy to environment variables. I would go for a new global option -c / --config, which like --verbose could be given to any command. This option would take an argument, which is a configuration file to parse and include at highest precedence (i.e. its settings would override the local configuration file's).

Example:

$ cat myconf.ini
[build]
board = nrf52dk_nrf52832
$ west -c myconf.ini build ... # gets build.board nrf52dk_nrf52832

@carlescufi - worth prioritizing?

[mbolivar-nordic]

@pabigot another less personal reason that I prefer -c is that environment-based approaches tend to be trickier to document and historically are not acceptable to as many Windows users as we would like.

[pabigot]

I admit to not personally being concerned about Windows support.

I can tolerate west -c ${WCFG} build ... where WCFG identifies the configuration for the board being worked on in that shell. Thanks.

[mbolivar-nordic]

An additional improvement we could consider is an --args FILE option that contains additional arguments to pass to the command.

[carlescufi]

I also prefer the .ini file approach, but my question would be, why not both? Many of this sort of configuration options can be specified both via env var and configuration option, and I do appreciate that env vars are widely used in the *NIX world.

@carlescufi - worth prioritizing?

Yes, but this will have to wait until the 0.9.x series (or a later iteration of the 0.8.x ones). We should release 0.8.0 as soon as possible.

[sjg20]

I actually find it annoying to use the same build directory for different boards. Removing files always makes me nervous. So I have started using /tmp/z/$board as the output dir.

I have been thinking about writing a simple script to build a board given its name and a target. The --force and -d flags are a pain.

I could avoid my script if something like:

west build

automatically set the above args, which I suspect would be possible with a config file that supports $board and other known vars.

[mbolivar-nordic]

@sjg20 you may want to investigate the build.dir-fmt and build.guess-dir configuration options:
https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options

By the way, --force is not required either. Just set build.pristine to auto and a change of boards will cause a pristine build.

[mbolivar-nordic]

my question would be, why not both?

@carlescufi I guess we could, but it would involve refactoring the configuration code to fall back on environment variables every time as requested by @pabigot. Personally I find heavy support for environment variables makes reproducibility harder, but if there's a lot of desire for this I'd be willing to add that too.

Note that our configuration code is also part of the problem where #149 is concerned, and I'd want to move the configuration state into the individual WestCommand objects then deprecate the functions that rely on global state in the west.configuration module as part of this work, especially if we are also going to introduce environment variable fallbacks.

[marc-hb]

This would be my preference, due to a slight personal allergy to environment variables. I would go for a new global option -c / --config, which like --verbose could be given to any command. This option would take an argument, which is a configuration file to parse and include at highest precedence (i.e. its settings would override the local configuration file's).

This 4th west config level would be the ideal solution to sign different build directories with different rimage parameters:

• intel_adsp: move west sign from west flash to earlier west build zephyr#54700

EDIT: maybe it would help with situations like #677 too

[marc-hb]

@thorsten-klein you should find this 2020 idea interesting. It's related to today's discussions in your:

• Support west config --update <file> #847
• Is there any reason why .west/config is in INI format? #848

It could be extended to a west -c config.d/NNN-multiple.conf approach as just discussed.

cc:

• @pdgendt
• @decsny