[HELP] Encapsulating Kconfig options in Arch files

[stbenn]

Description

For arch configuration, is it acceptable to use separate Kconfig files for logical blocks of the configuration? I am not proposing rework of already implemented Kconfig files, but would it be acceptable for new development?

I experimented with the H5 arch and it appears to work just fine. I moved the peripheral selection menu options from arch/arm/src/stm32h5/Kconfig to a new file arch/arm/src/stm32h5/Kconfig.periph_select. Then replaced the original Kconfig options with source arch/arm/src/stm32h5/Kconfig.periph_select. The menu inside menuconfig remained the same, and it compiled without issue.

Reason for wanting to do this: The H5 Kconfig is currently ~5k lines long, and will continue to expand as we add support for more peripherals. Encapsulating some of the options into separate files would make it easier to parse and validate configuration options.

Verification

• I have verified before submitting the report.

[raiden00pl]

I'm against this as long as it's a change only for stm32h5. All stm32 ports should look the same for easier maintenance. I don't think multiple Kconfig is a bad idea, I think the lack of consistency between stm32 ports is bad. On the other hand, fixing all the other stm32 is a lot of work and an additional mess in git history, which I'm not sure is worth the effort. All the stm32 Kconfigs are huge (stm32/Kconfig has 12k lines) and this is nothing new and I think we have to live with it for now.

[stbenn]

I agree that changing all of the stm32 Kconfigs is probably not worth the effort. The process of splitting them into submenus is relatively easy and quick, but testing the refactor would be difficult.

Based on the explanation of "source" in the docs (https://docs.kernel.org/kbuild/kconfig-language.html#kconfig-syntax), I thought maybe it would be possible to 'peek' at a fully parsed file used with make menuconfig (like a C file after the preprocessor expands everything) but a quick google search indicates this is NOT the case. If this file did exist, could make an automated tool to compare the output before/after separating the Kconfig files to verify the output is identical.