On Tue, Dec 17, 2024 at 8:12 AM <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
Also, if A uses "select B" and you select A, it will select B. But if you change your mind and deselect A, it does not deselect B automatically. So if you go through the menus and experiment with selecting and deselecting different things, you'll end up with extra stuff selected that you may not be aware of. More below... 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 a sensible rule of thumb. I remember reading it somewhere before. For non-visible items, select makes more sense. For visible (user-selectable) options, the user should explicitly control what is selected and what isn't. Nathan
