Hi, On Fri, 31 Aug 2007, Jan Beulich wrote:
> Doing a few more experiments with choices, I find that int, hex, and string > don't seem to work at all here. It would seem to me that these all could be > useful, but clearly would require some changes even in the grammar in order > to get there. Well, in the long term I wouldn't mind making choices more flexible, basically as a general way to describe more complex interdependencies between symbols, although I'm not sure how string symbols are useful here. The basic problem is to keep the syntax and user interface sane and there has to be a mechanism to resolve conflicts between these dependencies. > Also I think that deriving the choice type from the type of the first choice > value isn't always correct - at least not in the case of a mixed set of bool/ > tristate values, in which case the choice should become tristate itself. I'm not entirely convinced, mixing types is a good idea, but anyway... :) > --- a/scripts/kconfig/menu.c > +++ b/scripts/kconfig/menu.c > @@ -238,6 +238,9 @@ void menu_finalize(struct menu *parent) > /* find the first choice value and find out choice type > */ > for (menu = parent->list; menu; menu = menu->next) { > if (menu->sym) { > + if (sym->type == S_TRISTATE && > + menu->sym->type == S_BOOLEAN) > + break; > current_entry = parent; > menu_set_type(menu->sym->type); > current_entry = menu; If we allow for mixed types, then I guess the best rule would be to default to bool for choices, unless a child is a tristate. So it should look like: if (sym->type == S_UNKNOWN) { type = S_BOOLEAN; for_each_child if (child == S_TRISTATE) type = S_TRISTATE; menu_set_type(type) } For later parentdep is also set to NULL shortly after. > @@ -326,7 +329,9 @@ void menu_finalize(struct menu *parent) > "values not supported"); > } > current_entry = menu; > - menu_set_type(sym->type); > + if (sym->type != S_TRISTATE || > + menu->sym->type != S_BOOLEAN) > + menu_set_type(sym->type); > menu_add_symbol(P_CHOICE, sym, NULL); > prop = sym_get_choice_prop(sym); > for (ep = &prop->expr; *ep; ep = &(*ep)->left.expr) A test for S_UNKNOWN is better here. This would also be the place to move adding the parent dependency from above: if (menu->sym->type != S_TRISTATE) menu_add_dep(expr_alloc_comp(E_EQUAL, sym, &symbol_yes)); else menu_add_dep(expr_alloc_symbol(sym)); This adds a depency "<choice>=y", so that bools are only visible if the choice is 'y' and avoids the change in symbol.c. bye, Roman ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel