[Kai Germaschewski] > Well, it'd be nice to first "fix" the dep_* statements so that they > don't break when that change is done (i.e. in this case, moving > IDESCSI behind CONFIG_SCSI.
Yes. That's my current plan. > Basically, extend the "source" command to do a grep CONFIG_* in the > file to be read and set all found symbols to "n", if unset - only > then do the actual "source". Ugly - I'd rather not have to do it that way. (: > Anyway, some more points: > > o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs. > b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR > > (the latter proposed by Peter Samuelson) > > I see the following: > b) needs a large scale patch through all Config.in's. OTOH, it can be > done step by step, only changing an instance after it has been looked > at. a) means only a patch to Configure/menuconfig etc, but since it > changes semantics, it'd be nice to check all possibly breaking usages > (not too hard thanks to gcml2) sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case it is not hard to support both syntaxes - once the transition is complete, or reasonably complete, we can change the semantics to 'n'=='', which in Configure/Menuconfig can only be enforced in the non-$ case (well, unless we use your 'source' statement idea). > I find a) more intuitive, for people who know sh, it's pretty > clear when we use "$" and when not. Also, for 'if' statements, > we'll have to use the "$" variant anyway for all I can see, so I > prefer that from a consistency point of view. The problem with "intuitive for people who know sh" is that people think Config.in *is* shell. They start putting in constructs which are not valid Config.in syntax but which *are* valid sh syntax, so they work with certain parsers but not others. Mutating the language, long-term, so that it looks less like sh and more like a specialised language, is IMO a worthy goal. And I think it can be done. The main thing to deal with is adding an alternative syntax for 'if' statements which doesn't look like test(1). More about that in a separate message. > a) has the advantage of automatically getting rid of the ugly duplicated > 'if' tests: (And I think it should allow for getting rid of the > quotation marks, too) > > if [ "$CONFIG_FOO" = "" -o "$CONFIG_FOO" = "n" ] > --> if [ "$CONFIG_FOO" == "n" ] > if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ] > --> if [ "$CONFIG_FOO" != "n" ] See above - 'if' is due for an overhaul as well. > o whatever we do, having a nice way to handle two exclusive drivers would > be nice You mean the case where A=y implies B=n B=y implies A=n A=m implies B<=m B=m implies A<=m I agree. Not sure if it needs special casing or just better general facilities. I think it can be well served by the dep_* !CONFIG_FOO patch, where !y==n, !n==y, !==y, and !m==m. Then dep_tristate CONFIG_A !CONFIG_B dep_tristate CONFIG_B !CONFIG_A Peter ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
