On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
[ I was wondering whether to reply or not (this has become sort of a
a dead thread and subsumed by Sam's proposal to scan all Kconfig
files, but still) ... ]
Satyam Sharma wrote:
> On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> config A
>> bool-or-tristate "option A"
>> depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X
>
> ??? I didn't get this entry,
"A is available if N is there or if it's a platform other than X."
That would be adequate if N is only present and required on platform X.
Umm, if A requires helper code N (which is available only on platform X),
then why/how do we want A to depend on platforms _other_ than X?
That "||" OR there is totally incorrect, because it allows A to be selected
even _without_ N, which won't even allow A to build properly! Remember,
something "depends on" or wishes to "select" some other thing only if
it *reuses code exported* by the dependency.
Beginning to wonder if you even _understood_ the problem that was
being solved there ... I seriously recommend that if / when you _really_
think you have some good idea to solve some problem, then submitting
a working patch is invariably always better (and causes lesser noise :-)
> can you give a solid example
Nothing exactly of this sort, but compare for example kernel/power/Kconfig:
config SOFTWARE_SUSPEND
bool "Software Suspend (Hibernation)"
depends on PM && SWAP && (((X86 || PPC64_SWSUSP) &&
(!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP))
Of course this could be written in a clearer fashion, for example as
depends on PM
depends on SWAP
depends on (X86 && !SMP) ||
(X86 && SUSPEND_SMP) ||
(PPC64_SWSUSP && !SMP) ||
(PPC64_SWSUSP && SUSPEND_SMP) ||
(FRV && !SMP) ||
(PPC32 && !SMP)
Ok, so perhaps you actually meant X && N_ON_X above. But your
suggestion is _still_ wrong. Using "depends on" instead of "select" does
get rid of the warnings, but that conversion would *not* maintain current
behaviour (that of the config option being visible and automatically
selecting its dependency -- "default y if ..." otoh does preserve current
behaviour and hence _can_ replace select).
This is precisely what Trent meant that the kind of dependencies you
were suggesting in your mails can't be "select"ed in the first place.
Anyway, I've had enough of this thread. The patch that I had sent was
a 7-line *triviality* that merely (1) preserved current behaviour, (2) did
not cause _any_ build problems, and (3) got rid of bogus warnings in
a way that was completely standard when dealing with arch/.../Kconfig's
and better than the initial suggestion by Sam. Can't quite understand
how this became such a fiasco that ruined my Sunday :-)
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
