Linux内核Kconfig中的“选择”与“依赖”有什么区别？

内核Kconfig文件之间select和depends on内核Kconfig文件之间的依赖关系有何不同？

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.

在上面的示例中，与和有何FB_CIRRUS不同？FB && (ZORRO || PCI)FB_CFB_FILLRECTFB_CFB_COPYAREAFB_CFB_IMAGEBLIT

更新资料

我注意到depend on在编译顺序方面并没有真正做很多事情。

例如。成功构建AppB取决于首先构建静态链接的LibB。depends on LibB在Kconfig中为AppB 设置不会强制首先构建LibB。设置select LibB将。

depends on表示必须先肯定选择符号（=y），然后才能配置此选项。例如，必须选择depends on FB && (ZORRO || PCI)均值FB，然后选择（&&）ZORRO或（||）PCI。对于诸如之类的东西make menuconfig，这确定是否显示选项。

select积极地设置一个符号。例如，select FB_CFB_FILLRECT将表示FB_CFB_FILLRECT=y。这满足了某些其他配置选项的潜在依赖性。请注意，内核文档不建议将其用于“可见”符号（可由用户选择/取消选择）或本身具有依赖性的符号，因为不会对其进行检查。

参考：https : //www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

depends 表示该选项仅在满足其先决条件（其背后的布尔构造）的情况下才会显示在菜单中。

select表示当用户选择此选项时，作为参数to给出的选项select将被自动选择。

我想考虑的是：

• select是的“子集” depends，用于某个功能仅具有一种可能的依赖性的情况。

  由于只有一个可能的依赖项，因此select只需自动选择该选项，即可省去先手动手动选择依赖项的工作。

  这种自动化是您从仅具有一个可能依赖项的子集限制中获得的收益。

• depends 更通用，适用于某个功能依赖于具有多个实现的接口的情况。

  例如，在4.15上，有2个BPF实现：经典和扩展。

  因此，此BPF_JIT功能取决于至少一个启用的实现：

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  由于有两种可能的实现BFP_JIT，Kconfig无法明智地自动选择正确的实现。

  有时我希望我能说：“但是，如果不满足任何依赖关系，则默认情况下选择此依赖项”，这样可以进一步实现自动化。

也有“菜单配置中的东西隐藏了另一个选项”的效果，但是这些只是绒毛:-)