On Thu, 23 Apr 2020, Jason Gunthorpe wrote: > On Thu, Apr 23, 2020 at 11:11:46AM -0400, Nicolas Pitre wrote: > > On Thu, 23 Apr 2020, Jason Gunthorpe wrote: > > > > > On Thu, Apr 23, 2020 at 11:01:40AM -0400, Nicolas Pitre wrote: > > > > On Wed, 22 Apr 2020, Randy Dunlap wrote: > > > > > > > > > On 4/22/20 2:13 PM, Nicolas Pitre wrote: > > > > > > On Wed, 22 Apr 2020, Jani Nikula wrote: > > > > > > > > > > > >> On Tue, 21 Apr 2020, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > > > > >>> This is really a conditional dependency. That's all this is about. > > > > > >>> So why not simply making it so rather than fooling ourselves? All that > > > > > >>> is required is an extension that would allow: > > > > > >>> > > > > > >>> depends on (expression) if (expression) > > > > > >>> > > > > > >>> This construct should be obvious even without reading the doc, is > > > > > >>> already used extensively for other things already, and is flexible > > > > > >>> enough to cover all sort of cases in addition to this particular one. > > > > > >> > > > > > >> Okay, you convinced me. Now you only need to convince whoever is doing > > > > > >> the actual work of implementing this stuff. ;) > > > > > > > > > > > > What about this: > > > > > > > > > > > > Subject: [PATCH] kconfig: allow for conditional dependencies > > > > > > > > > > > > This might appear to be a strange concept, but sometimes we want > > > > > > a dependency to be conditionally applied. One such case is currently > > > > > > expressed with: > > > > > > > > > > > > depends on FOO || !FOO > > > > > > > > > > > > This pattern is strange enough to give one's pause. Given that it is > > > > > > also frequent, let's make the intent more obvious with some syntaxic > > > > > > sugar by effectively making dependencies optionally conditional. > > > > > > This also makes the kconfig language more uniform. > > > > > > > > > > > > Signed-off-by: Nicolas Pitre <nico@xxxxxxxxxxx> > > > > > > > > > > Hi, > > > > > > > > > > If we must do something here, I prefer this one. > > > > > > > > > > Nicolas, would you do another example, specifically for > > > > > CRAMFS_MTD in fs/cramfs/Kconfig, please? > > > > > > > > I don't see how that one can be helped. The MTD dependency is not > > > > optional. > > > > > > Could it be done as > > > > > > config MTD > > > depends on CRAMFS if CRAMFS_MTD > > > > > > ? > > > > No. There is no logic in restricting MTD usage based on CRAMFS or > > CRAMFS_MTD. > > Ah, I got it backwards, maybe this: > > config CRAMFS > depends on MTD if CRAMFS_MTD > > ? Still half-backward. CRAMFS should not depend on either MTD nor CRAMFS_MTD. It is CRAMFS_MTD that needs both CRAMFS and MTD. Furthermore CRAMFS_MTD can't be built-in if MTD is modular. Nicolas
