Peter Samuelson wrote:
>
> [Kai Germaschewski]
> > I didn't look into like choice statements, but I'd hope it's
> > possible to add dependencies to them, too, for consistency.
>
> I agree. Actually, if we're changing 'choice' anyway, it should be
> redesigned. Status quo takes three arguments:
>
> choice 'prompt string' 'choice-text-1 CONFIG_CHOICE1 choice-text-2 CONFIG_CHOICE2'
>'choice-text-default'
>
> This is bad because it pretty much requires multi-line strings, and
> because the choice texts cannot have spaces in them. In my opinion it
> should take a variable number of args:
>
> choice 'prompt string' 'choice text 1' CONFIG_CHOICE1 'choice text 2'
>CONFIG_CHOICE2 CONFIG_CHOICE_DEFAULT
This has already been invented, it's called "nchoice", it's been documented
in config-language.txt for some time, and I have working patches to implement
it in all three bundled parsers.
> I suppose you could then extend it with dependencies by putting those
> at the end. That makes for minor parsing problems, since you have to
> detect which arguments are which - basically I guess you look for two
> CONFIG_* in a row.
The problem is that "nchoice" really only gives you spaces in sub-prompts;
is not expressive enough to cleanly handle some of the cases in the existing
corpus. For example,
# arch/ia64/config.in
if [ "$CONFIG_ITANIUM" = "y" ]; then
choice 'Kernel page size' \
"4KB CONFIG_IA64_PAGE_SIZE_4KB \
8KB CONFIG_IA64_PAGE_SIZE_8KB \
16KB CONFIG_IA64_PAGE_SIZE_16KB" 16KB
else
choice 'Kernel page size' \
"4KB CONFIG_IA64_PAGE_SIZE_4KB \
8KB CONFIG_IA64_PAGE_SIZE_8KB \
16KB CONFIG_IA64_PAGE_SIZE_16KB \
64KB CONFIG_IA64_PAGE_SIZE_64KB" 16KB
fi
What this is trying to do is make the "64KB" entry visible only when
CONFIG_ITANIUM=n, and the hack is to provide two separate nearly-identical
"choice" statements. This works OK in config & menuconfig but looks down-
right strange in xconfig.
CML2 handled this by admitting that a "choice" is really a funny kind of
menu, and the parts of a "choice" are really "bool"s which have an extra
exclusivity semantic attached. So visibility conditions could be set on
individual choice items, because they were menu nodes just like "bool"s.
If you wanted to add the ability to express this in CML1, you would need
a completely different syntax for choices, say something like this:
menuchoice next_comment
comment 'Kernel page size'
choiceitem '4KB' CONFIG_IA64_PAGE_SIZE_4KB
choiceitem '8KB' CONFIG_IA64_PAGE_SIZE_8KB
choiceitem '16KB' CONFIG_IA64_PAGE_SIZE_16KB default
if [ "$CONFIG_ITANIUM" != "y" ]; then
choiceitem '64KB' CONFIG_IA64_PAGE_SIZE_64KB
fi
endmenuchoice
i.e. "menuchoice" is a menu which takes only "choiceitem" children,
and "choiceitem" is just like a "bool" except it has an optional
extra argument to indicate it's the default item.
> I already rejected trying to do any sort of grouping - mostly because
> the shell parsers would choke on ( ) and nothing else looks as nice -
> so, since there is no way to group things, the precedence table needs
> to be as simple and clear as possible. I think my current proposal
> fits the bill.
Yes, grouping is Too Hard with shell parsers.
> According to MEC, Linus once said, "There are no default values, only
> default answers to questions." If a question is never asked, the
> value is never set. This property is used in 'make oldconfig', for
> one, although your proposed change wouldn't directly affect oldconfig.
I'd really rather not change this property, it's actually quite useful.
ESR ran into trouble when he made "" and "n" indistinguishable in the
.config file, and then tried to get CML2 to work with Giacomo Catenazzi's
autoconfigurator.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
