On Thu, 24 Jul 2025, Imre Deak <imre.d...@intel.com> wrote: > On Thu, Jul 24, 2025 at 05:31:28PM +0100, Ruben Wauters wrote: >> On Thu, 2025-07-24 at 12:26 -0400, Rodrigo Vivi wrote: >> > On Thu, Jul 24, 2025 at 12:02:37PM +0300, Imre Deak wrote: >> > > Selecting an option which depends on other options only works if >> > > the >> > > dependencies are guaranteed to be selected (as these dependencies >> > > will >> > > not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on >> > > DRM, >> > > MMU and KUNIT the first two of which are guaranteed to be selected >> > > for >> > > i915, but the last one is not. Hence, selecting >> > > CONFIG_DRM_KUNIT_TEST in >> > > i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being >> > > selected >> > > without the CONFIG_KUNIT dependency being selected. This causes at >> > > least >> > > the following compile error: >> > > >> my bad, I guess I fundamentally misunderstood how the Kconfig system >> worked, and assumed that if you selected one all the dependencies were >> automatically selected. I guess this passed me by in testing cause I >> already had CONFIG_KUNIT selected and didn't think to de-select it, >> apologies. > > IME, it's easy to get the Kconfig dependency semantics wrong. Unless I > get it wrong, 'depends on' will never select the options listed after > it, it only determines if its parent option is visible during manual > selection (and similarly if it's valid to select the same parent option > from an other option automatically with 'select'). Maybe 'depends on' is > a misnomer and 'visible if' or 'available if' would better describe its > purpose.
The problem with "select" is that it will force the symbol to a value without meeting the dependencies recursively the same way "depends on" does. Per kconfig-language.rst, "In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies." BR, Jani. -- Jani Nikula, Intel
