カーネルKconfigファイルのselect
と_depends on
_の依存関係の違いは何ですか?
_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_CFB_FILLRECT
_、_FB_CFB_COPYAREA
_および_FB_CFB_IMAGEBLIT
_よりもFB && (ZORRO || PCI)
にどのように関連していますか?
更新
_depend on
_はコンパイル順に関してはあまり機能しないことに気づきました。
例えば。 AppBの正常なビルドは、最初にビルドされる静的にリンクされたLibBに依存しています。 AppBのKconfigで_depends on LibB
_を設定しても、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
は、ユーザーがこのオプションを選択すると、select
の引数として指定されたオプションが自動的に選択されることを意味します。
私が考えたいのは次のとおりです:
select
はdepends
の「サブセット」であり、機能の依存関係が1つしかない場合に使用します。
可能な依存関係は1つしかないため、select
はそのオプションを自動的に選択するだけで、最初に手動で依存関係を明示的に選択する手間を省きます。
この自動化は、依存関係が1つしかないというサブセット制限から得られるものです。
depends
はより一般的で、機能が複数の実装を持つインターフェースに依存する場合に機能します。
たとえば、4.15では、クラシックと拡張の2つのBPF実装があります。
したがって、BPF_JIT
機能は、有効になっている実装の少なくとも1つに依存します。
config BPF_JIT
depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
BFP_JIT
には2つの可能な実装があるため、Kconfigは適切なものを適切に自動的に選択できませんでした。
「依存関係が1つも満たされていない場合は、デフォルトでこれを選択する」と言いたい場合がありますが、これにより、さらに自動化できます。
「何かがmenuconfigの別のオプションを隠す」効果もありますが、これらは単に綿毛です:-)