Re: [I] [HELP] Encapsulating Kconfig options in Arch files [nuttx]
stbenn commented on issue #16202: URL: https://github.com/apache/nuttx/issues/16202#issuecomment-2807610128 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [HELP] Encapsulating Kconfig options in Arch files [nuttx]
raiden00pl commented on issue #16202: URL: https://github.com/apache/nuttx/issues/16202#issuecomment-2804036165 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
[I] [HELP] Encapsulating Kconfig options in Arch files [nuttx]
stbenn opened a new issue, #16202: URL: https://github.com/apache/nuttx/issues/16202 ### 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 - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
