[Bug] make not working when compiling keymaps in userspace, whilst qmk compile does

Describe the Bug

I'm getting errors when compiling with make, whilst compiling with qmk compile works, when building keymaps in the new userspace feature.

Example, when using (running from the qmk_firmware folder):

qmk compile -kb handwired/onekey/kb2040 -km xxxx

It compiles successfully.

However, when using:

make handwired/onekey/kb2040:xxxx

I get:

QMK Firmware 0.23.2
Making handwired/onekey/kb2040 with keymap xxxx

 * Could not find keymap                                                                               [ERRORS]

builddefs/build_keyboard.mk:444: *** Invalid keymap.  Stop.
make: *** [handwired/onekey/kb2040:xxxx] Error 1
Make finished with errors

(Obviously xxxx is in the qmk_userspace folder, and was created with qmk userspace-add -kb handwired/onekey/kb2040 -km xxxx .)

Keyboard Used

handwired/onekey/kb2040

Link to product page (if applicable)

No response

Operating System

macOS

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.2
Ψ QMK home: /Users/user/dev/qmk_firmware
Ψ Detected macOS 12.7.2 (Intel).
Ψ Testing userspace candidate: /Users/user/dev/qmk_userspace -- Valid `qmk.json`
Ψ QMK userspace: /Users/user/dev/qmk_userspace
Ψ Userspace enabled: True
Ψ Git branch: master
Ψ Repo version: 0.23.2
Ψ - Latest upstream/master: 2024-01-09 19:24:11 +0800 (6cc56f3f8c) -- Added skiller_sgk50_s3 keyboard (#22382)
Ψ - Latest upstream/develop: 2024-01-10 12:48:19 +1100 (7a3183b8c8) -- LED drivers: change `write_pwm_buffer()` return type to `void` (#22869)
Ψ - Common ancestor with upstream/master: 2023-12-31 19:25:58 +0100 (90811118b7) -- docs(skeletyl): fix readme instructions (#22791)
Ψ - Common ancestor with upstream/develop: 2023-12-31 19:25:58 +0100 (90811118b7) -- docs(skeletyl): fix readme instructions (#22791)
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.3.1
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.2
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb1610)
Ψ - lib/chibios-contrib: 2023-07-17 11:39:05 +0200 --  (da78eb37)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

[ ] AutoHotKey (Windows)
[ ] Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

update from Discord convo.

sigprof — Apparently the problem here is that when the top-level Makefile invokes make ... -f builddefs/build_keyboard.mk recursively, it does not pass the QMK_USERSPACE value to that invocation, and build_keyboard.mk itself does not read it from qmk config.

sigprof — quick and dirty fix (maybe we should avoid passing QMK_USERSPACE when it's not actually set?):

diff --git a/Makefile b/Makefile
index ab30a17f58..512781e440 100644
--- a/Makefile
+++ b/Makefile
@@ -274,7 +274,7 @@ define PARSE_KEYMAP
     # Format it in bold
     KB_SP := $(BOLD)$$(KB_SP)$(NO_COLOR)
     # Specify the variables that we are passing forward to submake
-    MAKE_VARS := KEYBOARD=$$(CURRENT_KB) KEYMAP=$$(CURRENT_KM) QMK_BIN=$$(QMK_BIN)
+    MAKE_VARS := KEYBOARD=$$(CURRENT_KB) KEYMAP=$$(CURRENT_KM) QMK_BIN=$$(QMK_BIN) QMK_USERSPACE=$$(QMK_USERSPACE)
     # And the first part of the make command
     MAKE_CMD := $$(MAKE) -r -R -C $(ROOT_DIR) -f $(BUILDDEFS_PATH)/build_keyboard.mk $$(MAKE_TARGET)
     # The message to display

qmk / qmk_firmware