What is the difference between "select" vs "depends" in the Linux kernel Kconfig?

Question

What are the differences in dependencies between select and depends on in the kernels Kconfig files?

config FB_CIRRUS
tristate "Cirrus Logic support"
depends on FB && (ZORRO || PCI)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
This enables support for Cirrus Logic GD542x/543x based boards on
Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum.

In the example above, how is FB_CIRRUS diffrently related to FB && (ZORRO || PCI) than it is to FB_CFB_FILLRECT, FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT?

Update

I've noticed that depend on doesn't really do much in terms of compilation order.

For example. A successful build of AppB depends on a statically linked LibB to be built first. Setting depends on LibB in Kconfig for AppB will not force the LibB to be built first. Setting select LibB will.

Solution 1

depends on indicates the symbol(s) must already be positively selected (=y) in order for this option to be configured. For example, depends on FB && (ZORRO || PCI) means FB must have been selected, and (&&) either ZORRO or (||) PCI. For things like make menuconfig, this determines whether or not an option will be presented.

select positively sets a symbol. For example, select FB_CFB_FILLRECT will mean FB_CFB_FILLRECT=y. This fulfills a potential dependency of some other config option(s). Note that the kernel docs discourage the use of this for "visible" symbols (which can be selected/deselected by the user) or for symbols that themselves have dependencies, since those will not be checked.

Reference: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

Solution 2

depends means that the option only shows up in the menu if its prerequisites (the boolean construct behind it) are met.

select means that, when the user selects this option, the option given as argument to select will be auto-selected.

Solution 3

I like to think about is as:

• select is a "subset" of depends, for when there is only one possible dependency for a feature.

  Since there is only one possible dependency, select just selects that option automatically, and saves you the work of explicitly picking the dependency manually first.

  This automation is what you gain from the subset restriction of having only one possible dependency.

• depends is more general, and works on cases where a feature depends on an interface that has multiple implementations.

  For example, on 4.15, there are 2 BPF implementations: Classic and Extended.

  Therefore, the BPF_JIT feature depends on at least one of the implementations being enabled:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Since there are two possible implementations for BFP_JIT, Kconfig could not sensibly select the right one automatically.

  Sometimes I wish I could say: "if none of the dependencies is met, select this one by default" though, that would allow to further automate stuff.

There are also "something hides another option on menuconfig" effects, but these are just fluff :-)