Messages in this thread | ![/](/images/icornerl.gif) | | From | Jani Nikula <> | Subject | Re: [PATCH 00/11] drm: Restore helper usability | Date | Mon, 22 Apr 2024 20:14:53 +0300 |
| |
On Mon, 22 Apr 2024, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Arnd, > > CC kbuild > > On Mon, Apr 22, 2024 at 3:55 PM Arnd Bergmann <arnd@arndb.de> wrote: >> I'm not sure where this misunderstanding comes from, as you >> seem to be repeating the same incorrect assumption about >> how select works that Maxime wrote in his changelog. To clarify, >> this works exactly as one would expect: >> >> config HELPER_A >> tristate >> >> config HELPER_B >> tristate >> select HELPER_A >> >> config DRIVER >> tristate "Turn on the driver and the helpers it uses" >> select HELPER_B # this recursively selects HELPER_A >> >> Whereas this one is broken: >> >> config FEATURE_A >> tristate "user visible if I2C is enabled" >> depends on I2C >> >> config HELPER_B >> tristate # hidden >> select FEATURE_A >> >> config DRIVER >> tristate "This driver is broken if I2C is disabled" >> select HELPER_B > > So the DRIVER section should gain a "depends on I2C" statement.
Why should DRIVER have to care that HELPER_B needs either FEATURE_A or I2C? It should only have to care about HELPER_B. And if the dependencies of FEATURE_A or HELPER_B later change, that's their business, not DRIVER's.
BR, Jani.
> > Yamada-san: would it be difficult to modify Kconfig to ignore symbols > like DRIVER that select other symbols with unmet dependencies? > Currently it already warns about that. > > Handling this implicitly (instead of the current explict "depends > on") would have the disadvantage though: a user who is not aware of > the implicit dependency may wonder why DRIVER is invisible in his > config interface.
-- Jani Nikula, Intel
| ![\](/images/icornerr.gif) |