Jan,
In your menuconfig patch series to convert menu into menuconfig,
you used "if <new menuconfig symbol" quite often.
That causes serious issues with "select". E.g. currently "select
LEDS_CLASS" does not work, because it is inside a "if NEW_LEDS".
Of course, not much stuff is the target of "select", but classes and
their ilk often are.
What's the best solution for this? Drop the "if <menuconfig symbol>"
and add lots of "depends on <menuconfig symbol>"? Or hunt down every
symbol selected inside an if and add the required select for the
menuconfig symbol?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Monday 2008-03-24 05:05, Henrique de Moraes Holschuh wrote:
>
> In your menuconfig patch series to convert menu into menuconfig,
> you used "if <new menuconfig symbol" quite often.
>
> That causes serious issues with "select". E.g. currently "select
> LEDS_CLASS" does not work, because it is inside a "if NEW_LEDS".
>[...]
> What's the best solution for this? Drop the "if <menuconfig symbol>"
> and add lots of "depends on <menuconfig symbol>"? Or hunt down every
> symbol selected inside an if and add the required select for the
> menuconfig symbol?
It "does not work" either if LEDS_CLASS is put outside of the if block
and instead gets a "depends on LEDS_CLASS".
So I am not sure what the problem you perceive really is, other than
"enabling A selecting B depending on (turned off) C"-is-allowed. :)
On Mon, 24 Mar 2008, Jan Engelhardt wrote:
> It "does not work" either if LEDS_CLASS is put outside of the if block
> and instead gets a "depends on LEDS_CLASS".
So, select is not walking the dep chain. Bad form, that, but I am sure
it is for a good reason. Well, select NEW_LEDS plus select LED_CLASS it
is, then. I'd have appreciated the Kconfig toolchain warning me of it,
but maybe I just don't know how to ask it to :-)
Thanks for the fast reply.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Monday 2008-03-24 07:54, Henrique de Moraes Holschuh wrote:
> On Mon, 24 Mar 2008, Jan Engelhardt wrote:
>> It "does not work" either if LEDS_CLASS is put outside of the if block
>> and instead gets a "depends on LEDS_CLASS".
>
> So, select is not walking the dep chain. Bad form, that, but I am sure
> it is for a good reason. Well, select NEW_LEDS plus select LED_CLASS it
> is, then. I'd have appreciated the Kconfig toolchain warning me of it,
> but maybe I just don't know how to ask it to :-)
'select' is doing its job — it enables LEDS_CLASS. It leaves NEW_LEDS
off though, since LEDS_CLASS "only" has a 'depends' on NEW_LEDS,
and not a 'select'. This is kind of a discrepancy for Kconfig rather
than a bug; it gets two inputs:
- CONFIG_FOO tells me to enable LEDS_CLASS
- LEDS_CLASS tells me to disable LEDS_CLASS because NEW_LEDS is off
In the end, it leaves LEDS_CLASS=m in the .config file and NEW_LEDS=off.