mlyszczek commented on code in PR #2893:
URL: https://github.com/apache/nuttx-apps/pull/2893#discussion_r1888507561
##########
system/libuv/Kconfig:
##########
@@ -6,6 +6,7 @@
config LIBUV
bool "libuv asynchronous I/O Library"
default n
+ select PIPES
Review Comment:
I already replied on mailing list, but since not everyone reads that I will
post my mail here as well with my thoughts on that
Select gonna fail for "nested dependencies".
CONFIG_A depends on CONFIG_B which depends on CONFIG_C
If you select A, A will select B, but it will not select C automatically,
A will have to have both "select B" and "select C". This can lead to bugs
I - personally - prefer depends for visible (user selectable) entries. While
select can be used to select invisible entries like
```
config CHIP_X
bool "select chip X"
select HAVE_UART
select HAVE_SPI
```
If you don't want for user to miss on some features I also include reversed
config like:
```
comment "psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE"
depends on DISABLE_MQUEUE || !SYSTEM_EMBEDLOG
menuconfig SYSTEM_PSMQ
bool "psmq"
default n
depends on !DISABLE_MQUEUE && SYSTEM_EMBEDLOG
```
In this case if you have enabled mqueue and embedlog you will see selectable
`[ ] psmq`
otherwise you will see comment
`--- psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE ---`
This has number of perks:
- user see all potential features he can choose from, regardless of what is
currently selected
- end user will immediatelly and explicitly see what gets pulled for a config
- no chance to break with nested dependencies - if embedlog suddenly starts
to
require new option, only embedlog kconfig will have to be modified (with
new
depends on option)
- no illegal configurations are possible with depends (while it is possible
with
select)
So, rule of thumb - use select only for non-visible (non-selectable anywhere)
symbols - use depends everywhere else.
--
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]
