Kconfig: The difference between 'def_bool y' and 'default y'

(07:53) - You are now in #zephyrproject
(07:53) - Topic: Zephyr Project opensource RTOS for IoT |  https://www.zephyrproject.org/developers/
(07:53) - Topic was set by [email protected] in 14.02.2018 at 01:04:40
(08:29) - glima quit (Ping timeout: 252 seconds)
(08:55) - inakypg quit (Remote host closed the connection)
(08:57) Hi, How to make a distinction between 'default y' and 'def_bool y' in Kconfig system?
(08:57) qianfan: 'def_bool y' is just a shorthand for 'bool' + 'default y'
(08:58) config FOO
(08:58)     bool
(08:58)     default y
(08:58) is the same as
(08:58) config FOO
(08:58)     def_bool y
(08:59) can be handy if you have some more complicated expression, like this one:
(08:59) Thanks, and I find there has a menuconfig in drivers/gpio/gpio_sam: 'menuconfig GPIO_SAM, bool "Atmel SAM GPIO (PORT) driver', should I use 'def_bool y' ?
(09:00) config HAS_SCREEN
(09:00)     def_bool SCREEN_1 || SCREEN_2 || SCREEN_3
(09:00) kinda dumb examples, but should get the point :D
(09:01) qianfan: could just do a 'default y' there, since the type has already been given
(09:02) Seems it isn't a error if I use 'def_bool y' here, is it right?
(09:03) nah, not an error. it's giving the same type twice, so it's a bit redundant, but it's not problematic at least.
(09:03) you'd get a warning if you gave it a different type
(09:03) like 'def_int 3'
(09:04) this definition:
(09:04) config foo
(09:04) bool "foo"
(09:04) def_bool y
(09:04) is a shorthand for this:
(09:05) config foo
(09:05) bool "foo"
(09:05) def_bool y
(09:05) urr... a shorthand for this:
(09:05) config FOO
(09:05) bool
(09:05) prompt "foo"
(09:05) bool
(09:05) default y
(09:06) so not much pointing in using 'def_bool' there
(09:06) *point
(09:06) And I found most of SoC's Kconfig.defconfig.series using 'def_bool y', is there has a recommendation which one is better?
(09:06) 'default y' might be better in Kconfig.defconfig file, for an obscure reason
(09:07) if someone deletes the base definition of the symbol, then a 'default y' will mean that no type is given for the symbol
(09:07) and then you'll get a warning that the symbol has no type. that makes it easier to discover redundant symbols in Kconfig.defconfig files.
(09:07) other than that, either one is fine. it's just a small shorthand.
(09:08) Thanks you and I got it!
(09:08) np
(09:09) How about write a issue that advise the developers using 'default y' instead 'def_bool y' in Kconfig.default?
(09:09) might be nice to have a Kconfig best practices page at some point
(09:11) qianfan: if you want to clean it up, i'll jump in and approve at least :)
(09:11) should finish up some West-related stuff now though
(09:12) I think Kconfig best pratices page is very necessary, actually I don't know how to write a Kconfig file, I just copy-paste another Kconfig file and just modify
(09:13) So I want there has a practices page, at least tell me how to use 'default y'
(09:13) yeah, kconfig-language.txt could be a bit clearer in spots too :/
(09:16) qianfan: there is a more nitty-gritty explanation of how symbols get their value here btw: https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L132
(09:17) Thanks you, I will learn it
(09:17) - Lncn quit (Disconnected by services)
(09:18) basically, there are just three different ways for a symbol to get a value: a 'default', the user setting the symbol to a value, and a 'select'
(09:19) if the symbol has a prompt (like in 'bool "foo"'), then the user can give it a value
(09:19) if the symbol has no prompt or the user doesn't give it a value, then 'default' kicks in instead
(09:19) and 'select' just overrides everything. it can be risky. :)
(09:20) - GAnthony_ quit ()
(09:21) you can put conditions individually on defaults and prompts ('prompt "foo" if BAR' or 'default y if BAR'). usually, people use 'depends on' though. that puts the same condition on everything (disables all the prompts and defaults).
(09:21) if no defaults kick in (e.g. because they have been disabled like that), then the symbol gets the value 'n' (if it's a bool)
(09:22) seems 'select' can only enable 'bool' type, is it right?
(09:22) yup
(09:23) 'select' can easily lead to "spaghetti kconfig", so should be careful with it
(09:23) And what's the differences between menuconfig and config? seems both of them can set a 'bool' type
(09:23) you mean .config files?
(09:24) menuconfig is just a configuration interface
(09:24) No, I means something like this: 'menuconfig GPIO_SAM
(09:24) ahh
(09:24) it's just a presentation thing. if you use 'menuconfig', then you will get a separate menu in the menuconfig.py interface, instead of stuff being indented.
(09:25) doesn't affect symbol evaluation at all. just a style hint.
(09:25) all the symbols after the 'menuconfig' symbol that depend on it end up in the menu
(09:25) as long as they follow immediately after it
(09:26) eg:
(09:26) menuconfig USART_SAM
(09:26)     bool "Atmel SAM USART driver"
(09:26)     ...
(09:26) config USART_SAM_PORT_0
(09:26)     bool "ENABLE USART0"
(09:26) if you use 'config' instead, then they get indented instead
(09:26) - Sachiel quit (Ping timeout: 252 seconds)
(09:26) USART_SAM is menuconfig and USART_SAM_PORT_0 is config, both has bool type
(09:27) qianfan: note that the symbols after it have 'depends on USART_SAM'
(09:27) try jumping to USART_SAM in the menuconfig interface and see how it looks
(09:27) and then try changing it to a 'config' instead and see how it looks
(09:27) should clarify it :)
(09:28) USART_SAM contain USART_SAM_PORT_0 ~ USART_SAM_PORT_2
(09:28) yup, in a separate "menu"
(09:28) try changing it to 'config USART_SAM'
(09:28) seems 'menuconfig' is a specify 'config', it also can 'select' or set default value by using 'default y'
(09:29) yep, both 'config' and 'menuconfig' define symbols
(09:30) 'menuconfig' is 'config' + a hint to display it as a menu in the menuconfig.py interface
(09:30) just a style hint. doesn't affect anything else.
(09:31) Understand
(09:31) it's a bit weird, but it's worked like that for ages, and it works alright :)
(09:32)  Thanks you for teaching me the Kconfig
(09:33) no probs