Re: [RFC] select and dependencies in Kconfig

["Satyam Sharma" <satyam.sharma@gmail.com>]

On 5/16/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > >
> > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > > end up with unbuildable configs.
> >
> > BTW, this kind of situation happens often enough, so how about doing
> > the following: teach kconfig that if FOO selects BAR and BAR depends
> > on <expr>, we should act as if FOO had explicit depends on <expr>.
> >
> > Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> > turning FOO on will land us into unbuildable configuration (BAR turned on,
> > dependencies of BAR are not satisfied).  It really happens often enough to
> > be very annoying.  And we have fsckloads of dependencies that are there
> > only because of such scenarios.  Gets especially nasty when BAR is selected
> > by several dozens of options and dependencies of BAR change...
>
> [ First off, "select"ing BAR that itself "depends on" BAZ is evil and
> should be avoided, except where BAR is strictly library-like and thus
> has simple or few basic dependencies. Still, like you say, dependencies
> of BAR can change over time, or one could want to be lazy and wish to
> avoid burdening users with having to pick dependencies _before_ the
> option they're interested in -- especially with menuconfig not even
> showing options whose dependencies are not satisfied already. ]
>
> Anyway, I'd gotten into a couple of threads discussing precisely this over
> the last couple of weeks, and thought of more-or-less a similar solution:
> http://lkml.org/lkml/2007/5/7/332
>
> When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
> Build a complete dependency tree (FOO upwards), and show to the user all
> the other config options (such as BAZ) that will now have to be picked
> to satisfy user's selection of FOO without causing build breakages. If
> user says yes, we *select* BAZ too (so now it can't be un-selected). If
> user says no, FOO is not picked at all.
>
> On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> > Implementing that is pretty simply; the only thing I'm not sure how to deal
> > with is how to show such inherited dependencies in menuconfig et.al.
>
> On 5/16/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> > that the indirect dependency ends up getting really confusing at times,
> > but I don't think the notion is broken - just worrying about how to *show*
> > this to explain what is going on when people say "why can't I select X".
>
> For menuconfig / xconfig it _could_ simply be another dialog box that
> pops up the moment user picks FOO.
>
> For config/oldconfig/etc non-curses/graphics-based ones, we could do
> something like what "yum" does for package dependencies on Red Hat
> and Fedora. Once the entire thing is done, just run through the entire
> .config just generated, and build these complete dependency trees for
> all picked options, and thus compiling a list of all the BAZ'es that also
> need to be picked now to satisfy user's demand for the FOO's.
> Simple Y/n then follows.

One minor glitch here: BAZ may not be a "select"able dependency at all.
Like Al wrote, it could be an <expr> that is something like !SMP etc that
can't be meaningfully selected.
For that case, menuconfig / xconfig could simply show up a dialog
explaining why the user's selection of FOO can't be allowed, and
config/oldconfig/etc can simply refuse to write out the broken .config.