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
--
"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
Hi,
On Thu, 21 Nov 2002, Adrian Bunk wrote:
> 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?
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
Roman Zippel <[email protected]> writes:
> 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
--
`Life is a boundless sea of bitterness'
Hi,
> 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.
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
On Thu, Nov 21, 2002 at 05:55:42PM +0100, Roman Zippel wrote:
> Hi,
Hi Roman,
> On Thu, 21 Nov 2002, Adrian Bunk wrote:
>
> > 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?
>
> It was not missing accidentially, these symbols were defined with
> define_bool before.
>...
/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. ;-)
> bye, Roman
cu
Adrian
--
"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