Hi Werner,
> This strikes me as a remarkable omission in
> Documentation/kbuild/config-language.txt: it doesn't say much about
> evaluation order (e.g. what happens when conflicting verbs meet, in
> particular "unset" vs. anything else) or uniqueness requirements (e.g.
> using multiple "define_bool"s is okay, while using multiple "bool"s
> isn't).
>
> Michael, could this omission be intentional ? :)
Yes, it was. I couldn't get a handle on the semantics of multiple
definitions given that people can visit the tree in any order. So I
left it out of the document.
The worst offenders are things like CONFIG_RTNETLINK where parts of
some scripts want them to be user defined and parts of other scripts
want to define them automatically.
> Evaluation order is a bit of a problem right now: xconfig and
> menuconfig allow options to be probed before their definition, e.g.
> you could (just as an example) show CONFIG_KMOD only if CONFIG_SCSI
> is set. It works disturbingly well.
Yes -- it usually does what people want, but only as a result of kludges
with not enough formal semantics.
mconfig doesn't complain yet. The hard part is that it's useful
and good to test options that are *never* defined (typically because
drivers/foo/Config.in wants to look at some arch-specific options).
> Considering the sequential nature of make (old)config , it seems
> unlikely to me that anything other than strictly sequential
> evaluation will be the norm anytime soon.
I've thought about this. I think a dependency (a conditional test)
is valid only if the values being tested have been defined or asked
for earlier in the same menu or earlier in a parent menu. Definitions
in a *sibling* menu, even an earlier sibling menu, aren't adequate
because an mconfig/xconfig user is entitled to traverse the menu
tree in any order.
> This makes me wonder why "unset" is considered a hack for a language
> problem in config-language.txt (or did I mis-understand the comment
> there ?)
That is a different issue.
The problem is the way that the config programs read in the existing
configuration. The easy, obvious way is to "source .config" and set
all the variables. But this is wrong because it sets variables that
should not be set yet.
The correct way is to start with all variables set to "" (just like
a blank configuration). When executing a config line, if there is
an existing value, then pick up that existing value.
Linus phrased it this way a couple of years ago: "there are no default
values. There are only default answers to questions".
> BTW, I think getting all configuration inter-dependencies properly
> expressed in the various config.in files is a very worthwhile goal.
Me too.
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:24 EST