CMakeLists.txt REQUIRES is missing esp-hosted-tanmatsu on ESP32P4 -- lora.c fails to find esp_hosted.h

[CJvanSoest]

Summary

Since (at least) v0.5.5/v0.5.6, idf_component.yml correctly declares:

nicolaielectronics/esp-hosted-tanmatsu:
  rules:
    - if: target == esp32p4
  version: ">=2.12.3"

so the component manager does fetch esp-hosted-tanmatsu into managed_components/ for an esp32p4 build. But lora.c unconditionally includes it for that target:

#if defined(CONFIG_IDF_TARGET_ESP32P4)
#include "esp_hosted.h"
#endif

while CMakeLists.txt never lists it as a requirement:

idf_component_register(
	SRCS
		lora.c
	INCLUDE_DIRS
		"include"
	REQUIRES
		sx126x
)

REQUIRES/PRIV_REQUIRES is what actually grants a component the include path of a dependency in the ESP-IDF build system - just being resolved into managed_components/ isn't enough. Result, building any project that consumes tanmatsu-lora as a plain managed component (not already separately requiring esp-hosted-tanmatsu elsewhere in its own tree) on esp32p4:

managed_components/nicolaielectronics__tanmatsu-lora/lora.c:15:10: fatal error: esp_hosted.h: No such file or directory
   15 | #include "esp_hosted.h"
      |          ^~~~~~~~~~~~~~
BUG: component_requirements.py: cannot match original component filename for source component nicolaielectronics__tanmatsu-lora

Reproduced 2026-07-20 building CJvanSoest/meshcore against tanmatsu-lora ^0.5.5 (clean managed_components/dependencies.lock, ESP-IDF v5.5.1, idf.py build -DIDF_TARGET=esp32p4). Presumably tanmatsu-radio/tanmatsu-launcher don't hit this because they already require esp-hosted-tanmatsu elsewhere in their own component graph, which happens to satisfy the include path project-wide via their own main component.

Suggested fix

Add esp-hosted-tanmatsu to REQUIRES (gated on CONFIG_IDF_TARGET_ESP32P4, matching the source-level guard), e.g.:

if(CONFIG_IDF_TARGET_ESP32P4)
    set(lora_extra_requires "esp-hosted-tanmatsu")
endif()
idf_component_register(
	SRCS lora.c
	INCLUDE_DIRS "include"
	REQUIRES sx126x ${lora_extra_requires}
)

Related to #6 (also filed today) but a distinct root cause - that one is a GET_CONFIG wire-compat gap, this one is a build-time packaging bug that blocks compilation outright for any project not independently depending on esp-hosted-tanmatsu.

[CJvanSoest]

Related to #6 (same investigation, distinct root cause).

[CJvanSoest]

For anyone hitting this in the meantime: adding nicolaielectronics__esp-hosted-tanmatsu to REQUIRES or PRIV_REQUIRES in a local override of this component (i.e. shadowing the registry package under components/tanmatsu-lora/ with the same name) doesn't actually work around it — IDF's component_requirements.py logs cannot match original component filename for source component tanmatsu-lora and the include path never gets added regardless of which name variant is used. Ended up bypassing it with target_link_libraries(${COMPONENT_LIB} PRIVATE idf::nicolaielectronics__esp-hosted-tanmatsu) after idf_component_register() instead, which does work. Might be worth knowing if the upstream fix goes through the same REQUIRES path — worth testing it actually resolves cleanly for a local override scenario, not just a fresh managed-component build.

[CJvanSoest]

Confirmed the target_link_libraries() workaround (see comment above) builds clean and works correctly on-device (radio config screen loads fine against current radio firmware). Leaving this open since the actual upstream fix (adding esp-hosted-tanmatsu properly to REQUIRES, or whatever ends up working around IDF's apparent name-matching limitation for locally-overridden components) is still needed for anyone consuming this as a normal registry dependency.

[renzenicolai]

Please try again with 0.5.7 😄