> I would define three basic types: integer,
> string, and undefined. Booleans (and tri-states) are synonmous with
> strings. All comperiasons involving undefined varibles are false (breaking
> !(a!=b) being equivelent to a=b, but that is fairly normal). Between their
> first mention (including in a dependincy) and when they are assigned a
> value, all varibles are undefined.
No, undefined is not a type, it is a variable attribute. A variable of
any type can be defined or undefined.
> > Note: The following construction is wrong:
> > bool <label> <test_variable> <value>
> Any clue what they mean here? If this was ment to be parsed as defaulting
> to <value>, I'm not shure it's a bad feature (indeed, I think it's a good
> feature), but it isn't one that's supported by the current synthax. Such
> usages should be hunt down and shot...
Agreed, for default features, we have defconfig. Otherwise, the user is
smart enough to make the right choice (read the help "if unsure, say Y")
when he has to deal with new options.
> See the attached patch (vs. 2.1.87).
> (OK, this message is getting to long, so it is as a sepperate posting.)
I totally agree with this patch.
> All varibles should have a default defined by the approate defconfig before
> use. If not, its value is thought to be "". (Is this correct? Flat-config
> takes the value to be "n", I'm not certian of xconfig, and menuconfig takes
> the value to be "". One of them is obviously wrong, but which?)
No. If the variable is not defined in defconfig, it is _undefined_. It has
no value, and having no value is different of having the value ""
config, menuconfig, _and_ xconfig will take the value as being undefined,
because they are _scripts_. That's why we can have problems with tests
like if [ "$CONFIG_FOO" != " ]; because in this case, the test is true
when the variable is undefined !
> I think that the autoconf.h writing program should remain sepperate from the
> .config writer...
AFAK, it is now currently separated. It is generated by config/menuconfig
and xconfig, so I see no reason why the library could not handle it.
> I see no compeling reason to merge them... for one thing,
> the .config file is ment to be human-readable and modifible. If we merge,
> then that is in some jeporday.
I don't want to merge, I just want to have the library providing two
services : one is the generation of a .config, and the other is the
generation of an autoconf.h
> > II.1.2 second round
> > Change the syntax, that will be transparent for all back-ends, thanks to
> > our parsing library.
> Why are we checking that all [Cc]onfig.ins are compliant to the old standard
> before upgrading all of them to the new synthax?
MEC has a good answer for that: because it is very difficult to do a huge
modification of such a fundamental thing (without this tools, it is very
hard these day to manage to compile a kernel) in all the existing trees :
Linus one, davem one, and the mips tree. That's why we need to be
compatible first.
> Then again, the includes need to be done AFTER checking if that line should
> be parsed as in the current system, not before it as in C (the
> pre-processor, rather).
Hehe :) You make me smile :) It seems that you have not yet tried to parse
such a file in C :) The goal of the game is not to parse the config file
several times, so you have to parse everything before beginning to work
with it.
Look at the difference between menuconfig and xconfig : in menuconfig,
each time you modify something, a shell script part corresponding to the
actual menu is executed again, and the display is modified. In xconfig,
all options are always visible, only the way to display it
(enabled/disabled) changes. That's because the script is only parsed one
time, and that's why you _must_ use something like a preprocessor (or do
it in your lexical analyzer, as I did) to read the entire config.in file
in one pass.
> > dep_tristate 'foo' CONFIG_A CONFIG_B == y
> >
> > but we could also use
> >
> > dep_tristate 'foo' CONFIG_A CONFIG_B != m
> >
> > in order to avoid the definition of bogus options like in the sound
> > driver.
> Huha? I'm sorry, but that made no sense to me...
I wanted to write something like
CONFIG_A
n
m CONFIG_MODULE == y
y CONFIG_B != m
Look at the CONFIG_PARIDE_PARPORT bogus option to have a better
understanding of the problem.
> > My library also issue warnings for name that don't begin with CONFIG_
> I don't think that I like this (for the new synthax, that is)... Being able
> to do varible substitution for things like MAXIRQ is nice, so I think that
> not having a "CONFIG_" prefix should just meen that the varible is internal,
> and shouldn't be writen out to the .config file.
Right. That's why I just issue a warning, but continues to parse normally.
> CONFIG_BINFMT_JAVA
> !n
> m EXPERMENTAL == y
> y EXPERMENTAL = y
>
> So this would meen that CONFIG_BINFMT_JAVA defaults to n if never perviously
> defined (get rid of defconfigs), and can be set to m or y only if
> EXPERMENTAL is y. Simple enough. (Note that = and == should be identinal
> here -- we don't really want people setting options in the dependincy
> information.) (Also note that I didn't use a CONFIG_ prefix on EXPERMENTAL,
> as we don't really do code dependincies on it.)
>
> If CONFIG_EXPERMENTAL isn't defined, then we even don't offer the option, we
> simply set CONFIG_BINFMT_JAVA to n (differing from the current behivor of
> not setting it). I'm not to certian how I like that. It's closer to what's
> really going on, but it's also farther from what we really want
> (CONFIG_BINFMT_JAVA won't show up as new if CONFIG_EXPERMENTAL is ever
> defined.)
Agreed. Albert D. Cahalan suggested a good syntax for dependancies
instead of writing:
CONFIG_A = y -o CONFIG_A = m
we could simply put : CONFIG_A=my
and identically,
CONFIG_A != n && CONFIG_A != m
could be written like CONFIG_A!=nm
> How about somthing more complex: CONFIG_SB_MPU_IRQ...
> CONFIG_SB_MPU_IRQ
> !n CONFIG_SB = y
> (1-MAXIRQ) CONFIG_SB = y
>
> or is this nicer?
> CONFIG_SB_MPU_IRQ CONFIG_SB=y
> !n
> (1-MAXIRQ)
>
> This does some more complex stuff... We mix boolean and integer types here,
I don't like this mix. I don't understand its meaning
But variable substitution is a good thing
> Anybody see problems with this synthax? (Other then that the ! for default
> looks too much like negation -- anybody with a better idea? It can't be
> used as a option without messy quoting, and it shouldn't be a commonly-used
> wildcard character either...)
You could use § (the paragraph symbol)
> > Menu 'my main menu'
> > Menu 'title2'
> > EndMenu
> > Menu 'title3'
> > EndMenu
> > EndMenu
> Hmm... but what about comments that aren't really a menu-head ("MPU401 IRQ
> is only required with Jazz16, SM Wave and ESS1688.")
Of course I keep them, but the interest here is to store the label of a
menu in its declarattion instead of having to use the next_comment/comment
stuff.
> I like just replacing choice lists with single varibles that can take any of
> a number of values, just like the above:
> CONFIG_PROCESSOR
> 386
> 486
> 586
> 686
Yes, but this is related to the fact that you can do tests on data
variables. I don't know if it is a good thing. We should keep in mind that
simplicity is our best friend.
Regis "HPReg" Duchesne - Engineering Student at ***** ******** *****
www http://www.via.ecp.fr/~regis/
(O o) I use Linux & 3Com (1135 KB/s over 10Mb/s ethernet)
--.oOO--(_)--OOo.-----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu