LKML Archive on
help / color / mirror / Atom feed
From: "Jan Beulich" <>
To: "Sam Ravnborg" <>
Cc: "Roman Zippel" <>,
	"Randy Dunlap" <>, <>,
Subject: Re: non-choice related config entries within choice
Date: Wed, 16 Jan 2008 13:46:57 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>But one feature I really would like to see is named chocies so we can do stuff like:
>choice X86_PROCESSOR
>	bool "A generic X86 processor"
>	bool "A generic PowerPC processor
>The issue here is that we do not today allow the same config option
>to appear if more than one choice.

I want named choices, too, but for a different purpose (and not
unconditionally): Currently, a choice really can just be a selection
between individual boolean settings or (as the current intended
extension) a mixture of boolean and tristate values. String or
numerical values aren't permitted (and iirc they even cause the config
process to crash). Nevertheless there are a couple of example where
choosing between individual string or numeric values is intended (but
needs to be made work with the current infrastructure, meaning that
one first chooses between boolean values and then selects (or sets
through default values in prompt-less config options) the intended
string or numeric value.

What you want seems much more fundamental a change, and as I
understand it you really want the name just as a name space
separation mechanism.

>This is a mandatory feature before we can do a Kconfig covering all architectures.
>I guess there are other issues when we do:
>if X86
>source foo/bar/Kconfig
>if PPC
>source foo/bar/Kconfig
>Where we in foo/bar/Kconfig has a choice list.

That you be done with

if X86 || PPC
source foo/bar/Kconfig

then, I would think (which should be the default anyway if you want a
Kconfig covering all architectures).

>I just wanted to raise this now that you anyway are looking into choice
>related issues.


  reply	other threads:[~2008-01-16 13:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 11:18 Jan Beulich
2008-01-16 11:52 ` Sam Ravnborg
2008-01-16 13:46   ` Jan Beulich [this message]
2008-01-16 13:50     ` Sam Ravnborg
2008-01-19  4:44   ` Roman Zippel
2008-01-19  4:36 ` Roman Zippel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: non-choice related config entries within choice' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).