what does select statement mean in Kconfig file?

what does select statement mean in Kconfig file?

[jidong xiao]

Hi,
for example, what does the select statement mean?

config SERIAL_SH_SCI_CONSOLE
        bool "Support for console on SH SCI(F)"
        depends on SERIAL_SH_SCI=y
        select SERIAL_CORE_CONSOLE

Thanks
Jason Xiao

Re: what does select statement mean in Kconfig file?

[Robert P. J. Day]

On Sat, 21 Jul 2007, jidong xiao wrote:

> Hi,
> for example, what does the select statement mean?
>
> config SERIAL_SH_SCI_CONSOLE
>        bool "Support for console on SH SCI(F)"
>        depends on SERIAL_SH_SCI=y
>        select SERIAL_CORE_CONSOLE
>
> Thanks
> Jason Xiao

it forces the selection of that option.  it's sort of like a "depends
on" in reverse.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: what does select statement mean in Kconfig file?

[Stefan Richter]

Robert P. J. Day wrote:
> On Sat, 21 Jul 2007, jidong xiao wrote:
> 
>> Hi,
>> for example, what does the select statement mean?
>>
>> config SERIAL_SH_SCI_CONSOLE
>>        bool "Support for console on SH SCI(F)"
>>        depends on SERIAL_SH_SCI=y
>>        select SERIAL_CORE_CONSOLE
>>
>> Thanks
>> Jason Xiao
> 
> it forces the selection of that option.  it's sort of like a "depends
> on" in reverse.

It's not really in reverse.  It too marks a dependency in the same
direction as "depends on".  But the select statement additionally
instructs "make XYZconfig" programs to
  - expose the dependent option even if the required option is
    disabled,
  - silently enable the required option.

The latter is sometimes hard or impossible to satisfy.  Therefore the
select statement should be used with care, i.e. only for library-type
helper code which itself shouldn't depend on further options.
-- 
Stefan Richter
-=====-=-=== -=== =-=-=
http://arcgraph.de/sr/

Re: what does select statement mean in Kconfig file?

[Krzysztof Halasa]

Stefan Richter <stefanr@s5r6.in-berlin.de> writes:

> The latter is sometimes hard or impossible to satisfy.  Therefore the
> select statement should be used with care, i.e. only for library-type
> helper code which itself shouldn't depend on further options.

How about depending on common dependency?

Something like

config A
	bool XXX
	depends on ARM

config B
	depends on ARM
	select A


or:

if ARM
	config A
		bool XXX
endif

if ARM
	config B
		select A
endif
-- 
Krzysztof Halasa

Re: what does select statement mean in Kconfig file?

[Stefan Richter]

Krzysztof Halasa wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> 
>> The latter is sometimes hard or impossible to satisfy.  Therefore the
>> select statement should be used with care, i.e. only for library-type
>> helper code which itself shouldn't depend on further options.
> 
> How about depending on common dependency?
> 
> Something like
> 
> config A
> 	bool XXX
> 	depends on ARM
> 
> config B
> 	depends on ARM
> 	select A
> 
> 
> or:
> 
> if ARM
> 	config A
> 		bool XXX
> endif
> 
> if ARM
> 	config B
> 		select A
> endif

That's OK.  Or generally, if A depends on X and B wants to select A,
then it has to be guaranteed by whatever means that X is enabled,
because "make XYZconfig" cannot select recursively.  Duplicating A's
dependencies as dependencies for B is one way to ensure that A's
dependencies are satisfied when B selects A.  Another way is to select
not only A but also A's dependencies.

That's why I wrote "/shouldn't/ depend on further options" rather than
"/must not/ depend on further options".

But whatever you do, as soon as you add a "select A", you have to watch
if anybody eventually makes A dependent on something else.  Therefore
think twice before you use select.

Also, while select makes it easy for users to enable options, it makes
it somewhat difficult for users to /disable/ options.  So there are also
tradeoffs in usability.  This essentially means that you should never
select huge subsystems.  As I said, only library-like helpers are
suitable for select.
-- 
Stefan Richter
-=====-=-=== -=== =-=-=
http://arcgraph.de/sr/