Re: xconfig lossage

James Mastros (root@jennifer-unix.dyn.ml.org)
Mon, 16 Feb 1998 21:03:11 -0500 (EST)


On Mon, 16 Feb 1998, Michael Elizabeth Chastain wrote:
> I think this is ungainly, but not terminally broken:
>
> if [ "$ARCH" = "sparc" -o "$ARCH" = "i386" ]; then
> bool "has a fnord device" Y
> fi

(Note: If people think that now is not a good time to hold this discution,
please tell me.)

Hmm... If we are going to redisign the Config.in synthax (how about renaming
them to [foo].cfg at the same time -- makes it cleaner IMHO), lets do it
right this time. First, we need to define our objectives:

1) The ablity to define complex dependincy rules
2) Easy reading (for humans)
3) Easy parsing (for machines)
Anything I'm mising here?

OK... How about this synthax:

(dependincies) option value_1/value_2/...

Where option is the CONFIG_FOO. That part is simple enough...

Value_1 is a possible value (y/n/m...). Also, numbers and ranges should be
possible. Being able to say "(CONFIG_SB=y) CONFIG_SB_MPU_IRQ n/1-MAXIRQ"
would be a win, so we need somthing like "(CONFIG_ARCH=ia32 CONFIG_SMP=n)
MAXIRQ 16" is needed (IE the rule is that if there is only one option, then
that option is picked without asking the user).

Including subfiles is almost definatly good, so we need a way to include
them... how about INCLUDE foo.cfg (that is to say the first non-whitespace
word dosn't begin with a "(", and is "INCLUDE").

Common constructions at this point seem to be:
1. (CONFIG_FOO != n) CONFIG_BAR y/m/n
2. (CONFIG_FOO = y) CONFIG_BAR y/m/n
(CONFIG_FOO = m) CONFIG_BAR m/n

The first is simple... we just need to relise that any comparison involving
an undefined varible is false. (If CONFIG_FOO is undefined, "CONFIG_FOO != n"
is false, but so is "CONFIG_FOO = n".) (This shouldn't show up in pratice,
as everything should be initialised in defconfig.)

The second is harder to deal with, but I think this is acceptable:
(CONFIG_FOO != n) CONFIG_BAR CONFIG_FOO/m/n (I.E. options are only
presented once, even if they appear multiple times in the list.)

-=- James Mastros

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu