[RFC] Let's turn mraa's Kconfig options into a dedicated submenu

[alext-mkrs]

This one proposes a change I believe will make user experience with configuring mraa options better. Right now we present all options under External Sources as a plain list and that IMHO may mislead the user. My proposal is tu turn the CONFIG_MRAA into menuconfig and all other options would become sub-items - see screenshots below:

I had to remove select MRAA everywhere, as that caused options not to be shown in the menu (+we anyway select this in all our prj*.conf files).

Bundled are two smaller ones, a description correction and an addition of the NEWLIB_LIBC, we've discussed in PR #30 (@malikabhi05 mentioned other symbols as well, but let me start with just this one).

Let me know what you think on this.

[Propanu]

@alext-mkrs I like having dedicated menuconfig entries and in fact, the UPM team talked about this a little bit during early development. As long as this doesn't affect ISSM integration I don't see any issues with the changes.

[alext-mkrs]

Great :) I'd be glad to test the ISSM integration, if you could elaborate on the exact scenario you have in mind (I haven't used ISSM yet, so I'm not sure how exactly it integrates with zmraa).

[arfoll]

@Propanu tell us if this breaks ISSM config, if it does we can delay it into the next release.

[alext-mkrs]

@Propanu, any news to share on this one? Anything I could do to help getting it through?

[Propanu]

@alext-mkrs sorry, I didn't get a chance to confirm this yet. I'll check with @pylbert and @malikabhi05 as they might be able to speed things up a bit and come back with an answer.

[pylbert]

@alext-mkrs, I like these two ways to collapse MRAA (and UPM) into a submenu:

1. Similar to UPM, wrap all sub-options in a 'menu' and use 'depends on MRAA' to hide sub-options
   pro: MRAA can be enabled/disabled from the MRAA menu level, no need to go up one and select MRAA
   pro: Similar to HALs and Cryptography menus under External

   External menu level, MRAA/UPM are 'menus'
   

   MRAA menu level w/MRAA config selected
   

   MRAA menu level w/o MRAA config selected
   

2. The method offered in this PR (menuconfig MRAA)
   pro: Looks nice
   con: If user descends into MRAA-level menu without selecting MRAA option above, they need to go up one, select MRAA, then back in

   External menu level where MRAA/UPM are configs
   

   MRAA menu level w/MRAA config selected in external menu
   

   MRAA menu level w/o MRAA config selected selected in external menu
   

I'm prb fine either way as long as it's the same for MRAA and UPM. It would be nice if we matched the other menu options at the external level.

[alext-mkrs]

Thanks Noel. I've considered using menu when preparing this one, but one specific thing that turned me away was that when "support" option is selected, all suboptions roll out within the same level, IMHO making it less readable. But menuconfig makes the user select the "support" option first, to see suboptions, just like you mentioned. However in my opinion that's okay, because the Kconfig interface shows that empty [ ] and it looks natural [to me, anyway 😃] that I need to first mark it to have the inner part active.

I've also analyzed most of the tree when preparing this and menu and menuconfig are both used very actively (and intermixed even - e.g. the HALs tree), apparently just by choice of those who introduced those particular pieces.

We are heavily in the "like/dislike" zone I think, as you've summarized, neither one has any outstanding technical or maintenance-related pros or cons. I'm also all hands for unifying this for mraa and upm. Purely based on my aestetics outlined above, I'd still support the approach proposed in this PR and I'm ready to implement the same for upm. We could also use a coin toss or other highly technical means of choosing one vs. the other 😄

[pylbert]

Great summary.

Here is another piece of the puzzle.

The NEWLIB_LIBC config option can't be selected because it's defined as a 'choice' in zephyr/misc/Kconfig. As such, we should prb remove the 'select NEWLIB_LIBC' from our Kconfig files in favor of a 'depends on NEWLIB_LIBC' at which point, if NEWLIB_LIBC is not selected, users will NOT see the MRAA menuconfig option.

We could however show a 'hint' in a menu option:

menu "MRAA (depends on NEWLIB_LIBC)"
config MRAA
    bool
    prompt "Mraa Support"
    select NEWLIB_LIBC

I've filed a sighting in Zephyr for advice: https://jira.zephyrproject.org/browse/ZEP-1440

[alext-mkrs]

Ok, looks like Anas has done the needful and we are good to continue using 'select'. Thanks for raising that!