Re: [PATCH] kconfig: warn about complex selects

[Roman Zippel]

Hi,

On Sun, 4 May 2008, Vegard Nossum wrote:

> One other idea that might be feasible in terms of both correctness and
> usability: If a symbol foo does "select bar", maybe foo should simply inherit
> bar's dependencies? This allows foo to be visible in most cases (when the
> dependencies of foo and bar are both satisified), but won't brute-force-enable
> any symbols.

Well, select was introduced for exactly this purpose.

In general I don't think it's possible to warn about this without 
producing a lot a false positives. If that would discourage people from 
using select everywhere, it might be an option but I'm afraid it will only 
cause them to add even more selects just to shut up the warnings.

Here is an example patch from me just a few days ago that might qualify as 
complex select, but is quite valid:

http://marc.info/?l=linux-kernel&m=120960318111346&w=2

The problem is usually that an option which might be visible, is selected 
without all the necessary build dependencies. The question is now how do 
you want to identify options which are necessary?
In this example a simple dependency check would flag that NEW_LEDS isn't 
selected, but NEW_LEDS is a pure config dependency, i.e. it has no effect 
on the build process.

It's not an impossible problem, but it's not trivial either, so that I 
haven't spend any time on it and rather would like to spend the energy on 
fixing the problem properly instead of working around it. And the problem 
BTW isn't select itself, the problem is that all the Kconfig dependencies 
have grown and become more complex, so it's becoming increasingly more 
difficult to maintain and to use them - select was never meant to solve 
this problem...

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/