Peter Samuelson wrote: > > > You're willing to potentially perturb 2.4? > > This stuff is trivial enough, and easy enough to test, that I think it > could go in 2.4, yes.
I think you're underestimating the Gordian knot that is the CML1 corpus. > Obviously xconfig would need to be dealt with > in sync with the others, which I'm not doing during the prototyping / > idea-mongering stage. Fair enough. > > I'm pleased to see that you have preserved those semantics. There > > are many places in the corpus where a dep_* lists as a dependency a > > variable which is not defined until later, or is only defined in > > some architectures, or is never defined. Earlier today I tweaked up > > gcml2 to detect them and found 260 in 2.5.29. > > You give me too much credit. The main motivation for dropping the '$' > was to make possible the "" == "n" semantics. That the patch failed > to do so was accident, not design. Ah, well that's more disturbing. Changing the existing semantics, regardless of how broken we all agree they are, is asking for a world of trouble. To pick an example, in 2.5.29 drivers/ide/Config.in:17 is dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works in "make config" and "make allyesconfig" precisely because of the semantic that you wish to change. In fact this is the first one gcml2 finds, I don't particularly feel like trawling through the other two hundred-odd. Some of them are harmless, I don't know how many. > I know the current behavior is documented, but I had thought this was > because changing the behavior was not feasible due to our Bash-based > "JIT parsers". Yes, changing the behaviour is infeasible with shell-based parsers. However, there is now a body of rules which implictly depend on the semantics. > Can you provide a rationale for why the current > behavior is desirable? I wouldn't call it "desirable". I would use words like "clunky", "congealed", "unorthogonal", "riddled with errors", and "very hard to fix" like the rest of the config language. > 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" ? The problem is that logic in config language is implicitly four-state, with the null or empty value being a separate value distinct from y, m and n. The fact that both "" and "n" mean "don't build this object" to kbuild doesn't mean that "" and "n" are the same thing. This isn't really obvious. One example where there is a semantic difference between "" and "n" would be an autoconfigurator, where "n" would mean "I have probed for this hardware and it is not present" but "" means something like "I have not probed". > and I don't see any benefits other than that it's the status quo. I'm not defending the current syntax. It sucks and it's broken. But fixing it will break things that currently aren't broken (or more accurately are broken twice in opposite directions). If it's your intention to change the semantics of "", perhaps it would be better to add new statements which feature the new syntax and new semantics *only* and have no backwards compatibility baggage. An example of this approach is the "nchoice" statement, which does the same thing as "choice" but with a more civilized syntax. > > > + case "$arg" in > > > + y|m|n) ;; > > > + *) arg=$(eval echo \$$arg) ;; > > > > Don't you want to check at this point that arg starts with CONFIG_? > > Also, how about quoting \$$arg ? > > I suppose one could add sanity checks / diagnostics, but there are no > other valid cases, so that's all they would be. Yes, but there are invalid cases, and surely you don't want to help to *increase* the amount of bugginess in the rules corpus? Greg. -- 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. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
