New kconfig: Please add define_*
Hi Roman,
one thing that easily leads to errors is that the difference between e.g. bool and define_bool is less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated as define_bool. I've already found two places in sound/oss/Kconfig where this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. a define_bool with a string or prompt line or a bool without a string or prompt line?
I know this requiress a conversion of several Kconfig files but considering that this might prevent some confusion in the future I think it's worth it.
TIA
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedHi,
Quoted 8 lines · Adrian Bunk
one thing that easily leads to errors is that the difference between e.g. bool and
define_boolis less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated asdefine_bool. I've already found two places insound/oss/Kconfigwhere this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. adefine_boolwith a string or prompt line or a bool without a string or prompt line?
It was not missing accidentially, these symbols were defined with define_bool before.
I'll think about the define_* syntax, but I will not make the other syntax illegal. The current 'bool "prompt"' is already a shortcut for the more common requirement:
config FOO
bool prompt '...'
Also note that the role of the default has changed, a default cannot override a prompt anymore (it only provides a default value to the prompt). The define_* syntax might imply that this is possible, but it won't.
bye, Roman
Quoted 4 lines · Roman Zippel
Also note that the role of the default has changed, a default cannot override a prompt anymore (it only provides a default value to the prompt). The define_* syntax might imply that this is possible, but it won't.
I'd like to be able to override a prompt.
The reason is that in general it's nice for the arch-specific Kconfig file to include various other Kconfig files (using `source'), but sometimes an option that usually makes sense as user-definable -- and thus has a prompt -- _doesn't_ make sense on that particular architecture.
Currently it seems as if the arch-specific Kconfig can do several things in this case:
(1) Inline the more general Kconfig into the arch-specific Kconfig (with the offending option removed, and omit the `source'). This is undesirable for all the usual reasons (code duplication causes bit-rot etc).
(2) Document somewhere that users shouldn't ever set option FOO, even though it asks the question. This is confusing for users.
(3) Add a dependency on ARCH_BLAH or something to the definition of FOO. This is probably the cleanest solution, but tends to result in arch-specific knowledge being littered all over the place (though this is already a general problem with the config system).
It would nice if I could just say in my arch-specific Kconfig:
option FOO
bool
set n
which would force FOO to `n' regardless of any later declarations.
-Miles
Signature · 1 line
`Life is a boundless sea of bitterness'
Hi,
Quoted 7 lines
I'd like to be able to override a prompt.
The reason is that in general it's nice for the arch-specific
Kconfigfile to include various otherKconfigfiles (using `source'), but sometimes an option that usually makes sense as user-definable -- and thus has a prompt -- _doesn't_ make sense on that particular architecture.
Do you have a specific example? What I've seen so far (especially cris was full of it), was more used to override the user (and only worked with 'make oldconfig' anyway). Only because most users want to include specific drivers, doesn't mean all users have to include these drivers. I'm a bit afraid such a feature would be easily misused.
It sounds more like you want an autoconf, which generates a machine specific config. E.g. ppc already delivers several config files for different machines, which are selected with 'make <mach>_config'. Going into this direction sounds like a better idea.
bye, Roman
Quoted 1 line · Roman Zippel
Hi,
Hi Roman,
Quoted 11 lines · Adrian Bunk
Quoted 9 lines
one thing that easily leads to errors is that the difference between e.g. bool and
define_boolis less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated asdefine_bool. I've already found two places insound/oss/Kconfigwhere this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. adefine_boolwith a string or prompt line or a bool without a string or prompt line?
Quoted 3 lines
It was not missing accidentially, these symbols were defined with
define_boolbefore.
...
/me checks 2.5.44
You are right, it was a define_bool before. I thought "this must be a bug" and I didn't even read the comments above the options...
A define_bool might make it more obvious for dumb people like me that it is really intended the way it is. ;-)
Quoted 1 line
bye, Roman
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed