NXP HAL's CMake cache variables get parsed as Kconfig options and error out

[kesyog]

Background

Zephyr has some experimental, undocumented functionality that parses CMake cache variables that are named like Kconfig variables and merges this into a project's Kconfig configuration: https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/modules/kconfig.cmake#L208-L211

https://github.com/zephyrproject-rtos/zephyr/blob/main/modules/hal_nxp/mcux/mcux-sdk-ng/drivers/CMakeLists.txt creates many CMake variables with the CONFIG_ prefix.

Issue

When I build a sample project that uses the mimxrt595_evk/mimxrt595s/cm33 board, touch my prj.conf so that CMake re-generation occurs, and re-build, I run into Kconfig errors because the NXP HAL's CMake variables are mistakenly(?) parsed as Kconfig options because of their naming:

zephyr/misc/generated/extra_kconfig_options.conf:

CONFIG_MCUX_COMPONENT_driver.cache_cache64=ON
CONFIG_MCUX_COMPONENT_driver.flexcomm=ON
CONFIG_MCUX_COMPONENT_driver.flexcomm_usart=ON
CONFIG_MCUX_COMPONENT_driver.iap3=ON
CONFIG_MCUX_COMPONENT_driver.inputmux=ON
CONFIG_MCUX_COMPONENT_driver.lpc_gpio=ON
CONFIG_MCUX_COMPONENT_driver.ostimer=ON
CONFIG_MCUX_COMPONENT_driver.pint=ON

This leads to an error like:

zephyr/misc/generated/extra_kconfig_options.conf:9: warning: attempt to assign the value 'ON' to the undefined symbol MCUX_COMPONENT_driver.pint
...
error: Aborting due to Kconfig warnings

It seems like these CMake variables should be renamed. Is this a bug or am I doing something wrong?

[DerekSnell]

Converted to Issue #88135, closing this Discussion. Let's use the Issue for further communication.