xiaoxiang781216 commented on PR #2239: URL: https://github.com/apache/nuttx-apps/pull/2239#issuecomment-1868541250
> > > @xiaoxiang781216 but popen is not used by default by the project, so there is not possibility to it be disabled and break the relation. > > > > > > user may call both pipes and popen initially, and remove popen call later, and will surprise that linker complain pipes function can't be found after he remove CONFIG_SYSTEM_POPEN from defconfig. > > Xiang, if the user enable both features (not matter which order) and if later he/she disables popen, pipes still enabled. If his/her defconfig had popen enabled and later on popen feature was removed from menuconfig, I understand that pipes will not be found, unless other feature also selects it. But, if we change popen to select pipes, CONFIG_PIPES will be removed from defconfig after normalization. You see the bad side effect with select. > > I think in general "select" and "depends on" are similar, but although "depends on" is safer, it has a drawback because it "hides" that feature from newcomer users. But I agree with you, users should learn how Kconfig works and how to search and fix symbols dependence. > > > > I think "depends on" doesn't protect the feature as we are thinking, because the user could go there and enable manually the feature in the .config. > > > > > > The user will find that the feature doesn't enable actually because the dependence doesn't match, instead linker error. Why do you think `depends on` doesn't protect the feature? > > Because a beginner user could bypass the menuconfig enabling the feature directly editing the .config and then complain in the mailing list that NuttX functions are broken :-) > But I think it isn't a linker error. > > > And even worst, "depends on" hides the feature in menuconfig. > > > The user will search for it, will find it, but when he goes there the option is not there. I think this is a case where "select" is better than "depends on" > > > > > > The user need understand the basic Kconfig concept, I don't believe that they can work with NuttX or Zephyr/Linux efficiently if they don't understand `depends on` and `select`. > > Agree! > > > BTW, user still encounter the similar problem unless you change ALL `depends on` to `select`. > > Not in this case, because the user just need to use popen, so if he enable the popen examble it could automatically select the system open and the pipe. In the other hand I think "depends on" is safe if user doesn't see the example popen in the menuconfig. If we don't have a documentation saying that examples exists, it will become a hidden feature. > I mean there are many features which describe the dependence through `depends on` not `select`. We need fix them too, otherwise the user will complain again and again. > If you agree I can change the popen example to also select system popen, so the problem will not exist for end users so, basically all dependence will describe through `depends on`. Before you do that, I would suggest you search the relative discussion on the web. Both Linux/Zephyr already learn from the practice and suggest to avoid select as much as possible. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
