Hi, On Wed, 16 Jan 2008, Jan Beulich wrote:
> now that I finally found time to look into the problems that caused the > patch changing boolean/tristate choice behavior to be reverted I find > that due to the way things worked in the past there are a couple of > cases where config options not really belonging to the choice are inside > the choice scope (drivers/usb/gadget/Kconfig, arch/ppc/Kconfig, and > arch/mips/Kconfig are where I found such cases, and I hope this is a > complete list). > > The question is: Is it intended for this to work the way it used to, or > is it rather reasonable to change these scripts so that stuff dependent > upon the choice selection is being dealt with outside the choice scope? This is really a feature, try it with a visible option there which depends on a choice option. First for the choice type I think it's simpler to just look at the first choice option, anything more complex simply has to specify the type explicitly. The bigger problem is that menu_finalize() is little complex which makes such changes more difficult, basically it does two things (updating the dependencies and generating the menu structure) in one pass and it depends on a specific order, which is nonobvious. I really should clean this up to make it easier to follow what's happening. For now this means the dependency to the choice symbol has to be added a little later right before the call to menu_add_symbol(). bye, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
