If we have something like this in Config.in choice prompt "TEST" config BR2_TEST_1 bool "1" config BR2_TEST_2 bool "2" endchoice config BR2_TEST_BOOL_D1 bool "Depends on 1" depends on BR2_TEST_1 config BR2_TEST_BOOL_S1 bool "Selects 1" select BR2_TEST_1 config BR2_TEST_BOOL_D2 bool "Depends on 2" depends on BR2_TEST_2 config BR2_TEST_BOOL_S2 bool "Selects 2" select BR2_TEST_2 Then selecting BR2_TEST_BOOL_S1 or BR2_TEST_BOOL_S2 does not select BR2_TEST_1 or BR2_TEST_2. I am not sure if it is expected behavior but seems like a bug to me.
This is just how Kconfig works: it is not possible to "select" an option in a choice. We don't develelop Kconfig ourselves, we simply inherit it from the Linux kernel, so we are not in a position to fix this issue. I think the reason it is this way is that there is nothing stopping two configs to select two separate options from the choice. In your example, if both BR2_TEST_BOOL_S1 and BR2_TEST_BOOL_S2 are set to y, then both BR2_TEST_1 and BR2_TEST_2 would be selected. I think to fix this issue, you would need to put a full-fledged boolean resolver behind it. If you want a workaround for this limitation, take a look at openssl. It has a choice between libopenssl and libressl, but there is also the symbol BR2_PACKAGE_OPENSSL_FORCE_LIBOPENSSL. If that symbol is selected, the libressl choice is no longer available, so it is forced to openssl. Note that it is only possible to force it in one direction that way (so there is no BR2_PACKAGE_OPENSSL_FORCE_LIBRESSL) - otherwise, you'd be back in the same situation as your example; Kconfig reports this as a circular dependency.
(In reply to Arnout Vandecappelle from comment #1) Oh, sorry. I didn't know that it is Kconfig and that it is separate from buildroot. Big thanks for such a great explanation!