[OpenWrt-Devel] Config.in: why the occasional use of "select" instead of "depends"?
Robert P. J. Day
rpjday at crashcourse.ca
Sun Sep 14 14:18:40 EDT 2014
more of my annoying pedantry surfacing, but i'm puzzled as to the
occasional use of "select" in some Config.in files. case in point --
this in "toolchain/eglibc/config/Config.in":
... snip ...
config EGLIBC_OPTION_EGLIBC_CRYPT
bool "Encryption library"
default y
help
This option group includes the `libcrypt' library which
provides functions for one-way encryption. Supported
encryption algorithms include MD5, SHA-256, SHA-512 and DES.
config EGLIBC_OPTION_EGLIBC_CRYPT_UFC
bool "Ultra fast `crypt' implementation"
default y
select EGLIBC_OPTION_EGLIBC_CRYPT
... snip ...
assuming there are no other references to those two Config.in
variables, the above strikes me as just awkward and unnecessarily
obtuse.
rather than the second one "select"ing the first one, why doesn't it
just "depend" on the first one? first, would that not be entirely
equivalent?
more importantly, using "select" produces a potentially confusing
menuconfig session, where both options are visible, but
selecting/deselecting the second one magically changes the visual
appearance of the first.
once upon a time, there was a discussion on LKML regarding how many
people really, really despised the arbitrary use of "select" in config
files, because it produced magical side effects that reached across
the kernel source and screwed around with other submenus.
so, serious question, why select above and not depends?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list