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
