On Fri, 10 Mar 2000 almesber@lrc.di.epfl.ch wrote:
> Arjan van de Ven wrote:
> > At the end of "make config", check a set of declared "dependency rules" and
> > if they are violated, just give a warning-message and run a "make
> > quietoldconfig" so that only the relevant questions are asked again.
>
> Sounds like the third best solution:
> best: rearrange configuration such that the structure is clear, easy
> to understand, and no conflicts can arise (only problem: may be
> impossible ;-)
s/may be/is
> 2nd best: catch conflicts in the configuration editor and let users
> resolve them there
> 3rd best: catch them outside of the editor and use a different
> procedure to resolve them
My solution would fit in the 2nd category... (at the end of make config,
do the checks). menuconfig and xconfig need some changing as well, but the
"make config" case is the hardest...
> The 3rd best may still be better than nothing at all, provided that there
> is a useful migration path to a more integrated solution.
The migration path would be to throw the entire Config.in system out and
replace it with something more suitable (2.5.x). I have some ideas about
this and will post them soon to l-k.
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:17 EST