Michael Elizabeth Chastain wrote:
> 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).
What about complaining when you parse a definition of an option that
was read before ? Or, if complaining is too hard/boring to add (e.g.
to Configure or xconfig), just declare it illegal and let the
linux-kernel police take care of flaming any offenders ;-)
> 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.
Hmm, how do you define "menu" ? If you mean the structure of the
representation, I'd disagree, e.g.
"Peripheral buses"
bool CONFIG_ISA
bool CONFIG_PCI
bool CONFIG_EISA
...
"Network drivers"
if CONFIG_PCI ...
Looks valid and useful to me. Now, if you mean the conditional
structure, a typical counter-example could be:
if CONFIG_PCMCIA
bool CONFIG_CARDBUS
...
... somewhere deep in the network drivers ...
if CONFIG_CARDBUS
bool CONFIG_SOME_CARDBUS_ONLY_CARD
But maybe you mean something else ?
I think as a first step, requiring things to be compatible with
sequential evaluation is necessary, because Configure can't handle
backward references anyway. Further requirements or guidelines could
be built on top of this.
> [ unset ] is a different issue.
Oh, I see. Thanks for the clarification.
- Werner
P.S. Evil idea of the day: while writing the above meta-code, I
realized that bool "text" CONFIG_xx is in fact redundant,
and bool CONFIG_xxx should be sufficient - if people write
the corresponding Configure.help entry. Now wouldn't that be
a great way to enforce good documentation habits ? ;-)
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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:23 EST