config language dep_* enhancements]
PATCH 1/1 config language dep_* enhancements]
[Sorry, resent to lkml with attachment gzip'ed]
Quoted 10 lines · Kai Germaschewski
Quoted 4 lines · Greg Banks
But at this point in the menu tree for 14 of 17 architectures,
CONFIG_SCSIhas not yet been defined. The result is thatCONFIG_BLK_DEV_IDESCSIonly works in "make config" and "make allyesconfig" precisely because of the semantic that you wish to change.But so the change would be a good thing, right? It would make the behavior consistent between all configuration tools,
Sorry, I don't understand what you're getting at. Currently the behaviour is consistent between config, menuconfig and xconfig: null-valued deps are ignored.
Quoted 3 lines
CONFIG_BLK_DEV_IDESCSIwould
be not selectable in either. So people would have to notice that this statement is broken and fix it.
Ah. If you're willing to knowingly feed Linus with patches that break current config behaviour, then OK we have a way to proceed.
Quoted 5 lines
Quoted 2 lines
Yes, changing the behaviour is infeasible with shell-based parsers. However, there is now a body of rules which implictly depend on the semantics.
If they do, they should be fixed. And, as I pointed out before, it is possible to fix even shell-based parsers.
Sorry, didn't see that.
Quoted 1 line
So you agree a bit of spring cleaning wouldn't hurt, right? ;)
Absolutely, and I have a catalogue of dust puppies to help that process ;-)
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
It seems to me that it only encourages buggy
Config.in code (since "" == "n" in other contexts like the #defines),And "" != "n" in other contexts, like if [];then statements. Did I mention "unorthogonal" ?
Well, you're right here. Which makes me think of my original idea as to define all CONFIG_* values to "n" unless they've explicitly been assign another value before.
CML2's semantics were that all symbols have a default which is a zero; for booleans and tristates that means "n". Changing from those semantics to the ones necessary to run the gcml2 rulebase on CML1 rules was one of the most painful parts of supporting CML1.
So I think having an explicit "n" default is a good idea, but I fail to see how you would actually implement such a thing in a shell based parser.
Quoted 8 lines
The main usage currently is "make oldconfig", though .config may be a bit
confusing: Questions which have been answered before (even with "n") will not be asked again, whereas for undefined symbols, the corresponding question is put.So I think the logic should really be tristate, "n","m","y", plus additionally a list of CONFIG_* values which have been defined (as opposed to just being "n" by default).
This is precisely the CML2 semantics.
Quoted 1 line
Of course, this is a 2.5 change,
Agreed.
Quoted 2 lines
though the only potential for breakage
are the dep_* statements which are arguably already broken.
I don't think there's any value to gratuitously breaking 2.4's config. That's the point of a "stable" series right?
Quoted 4 lines
It shouldn't
be too hard to come up with a script which points out the dep_* statements which reference symbols defined only later (or use gcml2, which I understand can do that already?) to see how much breakage there may be.
Ah, glad you asked, see attached output from the latest version of gcml2 (not yet released).
Greg.
Signature · 3 lines
the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.