Re: [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword

[Jani Nikula]

On Tue, 21 Apr 2020, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
> On Tue, 21 Apr 2020, Saeed Mahameed wrote:
>
>> On Tue, 2020-04-21 at 09:58 -0400, Nicolas Pitre wrote:
>> > On Tue, 21 Apr 2020, Saeed Mahameed wrote:
>> > 
>> > > I wonder how many of those 8889 cases wanted a weak dependency but
>> > > couldn't figure out how to do it ? 
>> > > 
>> > > Users of depends on FOO || !FOO
>> > > 
>> > > $ git ls-files | grep Kconfig | xargs grep -E \
>> > >   "depends\s+on\s+([A-Za-z0-9_]+)\s*\|\|\s*(\!\s*\1|\1\s*=\s*n)" \
>> > >  | wc -l
>> > > 
>> > > 156
>> > > 
>> > > a new keyword is required :) .. 
>> > > 
>> > > 
>> > > > In another mail I suggested
>> > > > 
>> > > > 	optionally depends on FOO
>> > > > 
>> > > > might be a better alternative than "uses".
>> > > > 
>> > > > 
>> > > 
>> > > how about just:
>> > >       optional FOO
>> > > 
>> > > It is clear and easy to document .. 
>> > 
>> > I don't dispute your argument for having a new keyword. But the most 
>> > difficult part as Arnd said is to find it. You cannot pretend that 
>> 
>> kconfig-language.rst  ?
>> 
>> > "optional FOO" is clear when it actually imposes a restriction when 
>> > FOO=m. Try to justify to people why they cannot select y because of
>> > this 
>> > "optional" thing.
>> > 
>> 
>> Then let's use "uses" it is more assertive. Documentation will cover
>> any vague anything about it .. 
>
> It uses what? And why can't I configure this with "uses FOO" when FOO=m?
> That's not any clearer. And saying that "this is weird but it is 
> described in the documentation" is not good enough. We must make things 
> clear in the first place.
>
> This is really a conditional dependency. That's all this is about.
> So why not simply making it so rather than fooling ourselves? All that 
> is required is an extension that would allow:
>
> 	depends on (expression) if (expression)
>
> This construct should be obvious even without reading the doc, is 
> already used extensively for other things already, and is flexible 
> enough to cover all sort of cases in addition to this particular one.

Okay, you convinced me. Now you only need to convince whoever is doing
the actual work of implementing this stuff. ;)

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center