On Tue, Dec 17, 2024 at 2:12 PM <michal.lyszc...@bofc.pl> wrote: > On 2024-12-17 13:27:48, Tomek CEDRO wrote: > > Hello world :-) > > > > Recent PR #2893 [1] proposed using "select" statement for "PIPES" as > > dependency of "LIBUV" option. There is a preference to use "depends > > on" in that case [2]. What are your preferences and experiences in > > this area? Is there a policy / preference in this area for NuttX? :-) > > > > What are dangers of using "select"? Why "depends on" is preferred? > 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. > > -- > .-----------------.-------------------.----------------------.-----------------. > | Michal Lyszczek | Embedded C, Linux | Company Address | .-. > opensource | > | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| > supporter | > | https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\ & > | > | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) > programer | > `----------------------^--------------^----------------------^-----------------'
Thank you Michal for perfect explanation with real world examples!! :-) Looks like this policy is good for us (NuttX) and in align with other projects? 1. Kconfig "select" only for non-visible (non-selectable anywhere) symbols. 2 Kconfig "depends on" everywhere else. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
