Problem
The Makefile uses .ONESHELL, which means cd commands change the working directory for the rest of the recipe. Several firmware targets use cd ... && $(MAKE) ...:
cd $(CURDIR)/$(MPY_DIR)/ports/stm32 && $(MAKE) BOARD=$(BOARD) submodules # line 97
cd $(CURDIR)/$(MPY_DIR)/ports/stm32 && $(MAKE) BOARD=$(BOARD) submodules # line 103
cd $(CURDIR)/$(MPY_DIR)/ports/stm32 && $(MAKE) BOARD=$(BOARD) # line 109
cd $(CURDIR)/$(MPY_DIR)/ports/stm32 && $(MAKE) BOARD=$(BOARD) submodules # line 118
cd $(CURDIR)/$(MPY_DIR)/ports/stm32 && $(MAKE) BOARD=$(BOARD) deploy-openocd # line 124
With .ONESHELL, the cd persists after the $(MAKE) call, which can cause surprising behavior if later commands use relative paths.
Proposed fix
Replace all occurrences with $(MAKE) -C:
$(MAKE) -C $(CURDIR)/$(MPY_DIR)/ports/stm32 BOARD=$(BOARD) submodules
-C changes directory only for the sub-make invocation, without affecting the parent shell state.
Scope
All 5 occurrences in the firmware-related targets ($(MPY_DIR), firmware, firmware-update, deploy).
Context
Identified during review of PR #361 (Copilot comment). Not addressed there to keep the PR focused on the submodule auto-init fix.
Problem
The Makefile uses
.ONESHELL, which meanscdcommands change the working directory for the rest of the recipe. Several firmware targets usecd ... && $(MAKE) ...:With
.ONESHELL, thecdpersists after the$(MAKE)call, which can cause surprising behavior if later commands use relative paths.Proposed fix
Replace all occurrences with
$(MAKE) -C:-Cchanges directory only for the sub-make invocation, without affecting the parent shell state.Scope
All 5 occurrences in the firmware-related targets (
$(MPY_DIR),firmware,firmware-update,deploy).Context
Identified during review of PR #361 (Copilot comment). Not addressed there to keep the PR focused on the submodule auto-init fix.