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;
                        if (child == S_TRISTATE)
                                type = S_TRISTATE;

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 

        if (menu->sym->type != S_TRISTATE)
                menu_add_dep(expr_alloc_comp(E_EQUAL, sym, &symbol_yes));

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

Reply via email to