[Roman Zippel] > I really hate to spoil the fun
(: > but could someone explain to me, why this is necessary? What > problems does that fix? It's not necessary, technically - it doesn't directly fix any bugs. It falls under "cleanup", and as such, it is supposed to make bugs harder to write and easier to spot. The problems it solves are problems of readability and awkwardness in the current [Cc]onfig.in corpus. Basically the current discussion revolves around the best way to evolve the config language to make it more suitable for its purpose. This is of course in contrast to what ESR and you have tried, which is to replace the whole thing. My main goal is to make it easier to write Config.in files, by making the syntax and semantics less awkward. Certainly one side effect is that it will be possible to do automatic "(EXPERIMENTAL)" and "(OBSOLETE)" tags, but that has never been the primary intent. * The current 'if' statement is really ugly and unintuitive, unless you are comparing it to Bourne shell syntax, in which case it is merely ugly and *somewhat* unintuitive. (It is still unintuitive because it offers only a subset of Bourne shell functionality, and that subset is arbitrarily defined.) If you use Bourne shell syntax outside the config language spec, your file may break subtly in Configure or Menuconfig, or spectacularly in xconfig (since xconfig doesn't use the shell). Since most people don't test their changes on all three parsers, they may not notice. * Current 'if' semantics are hard to get right in many common cases. For example, a guard variable may be either unset ("") or False ("n"). If you want something to depend on the guard variable, you have to cover both cases with AND or OR. Many people do not think to do this. I am trying to design a replacement statement which *does* cover common cases easily, while not losing any of the flexibility we have now. The current state of my proposal gives quite a bit *more* functionality than we have now - some config files have the potential to become considerably simpler / shorter. * By having *one* standard syntax for dependency declarations, the whole language spec is more consistent and, incidentally, easier to write a parser for. (The fact that *human* parsing is easier as well is a related but separate advantage.) None of that answers your real question: why not use either CML2 or your work? Answer: evolution, not revolution. You say you have tried hard to keep the existing rulebase functionally identical (something Eric, of course, did not do). Fine, but so did Keith Owens when he wrote kbuild 2.5, and look where that got him. I have looked through the kbuild2.5 makefiles, and there were many places where Keith deliberately enforced things that looked completely arbitrary (link order in particular) merely for the sake of having an apples-to- apples comparison. So what did Linus do? He refused to take Keith's patches directly, but instead accepted Kai's incremental fixups to the current build system, which is nothing like Keith's system. Kai, in turn, made so many tweaks to the current system that it now resembles - in functionality if not in implementation - kbuild2.5. (Yes, the current build system is missing some features, but considering that there have been no radical changes, it's pretty impressive what Kai has managed to wring out of it.) I'm taking pretty much the same approach: removing warts from the current config system, one by one, to see how clean it can get. Perhaps eventually someone will be able to merge in a completely different system, but if so, as Greg has said, what we are doing now will lay the ground-work for such a change, by removing a lot of kludges from the rulebase. > The only reason I've seen so far is to make the generation of > "(EXPERIMENTAL)" possible. Is this really that important to risk new > problems? I happen to think the risk of new problems is relatively low. My experience with Menuconfig so far is that the types of features I am adding are relatively straightforward, and it's surprisingly easy to verify that things are all working correctly. I suppose xconfig will be the usual nightmare - perhaps Andrzej (the de facto xconfig maintainer) will help out when the time comes - but Configure and Menuconfig have presented no major problems so far. There *is* the risk of adding bugs when changing the rulebase, but those will be isolated to individual rule files, and should be easy to debug if and when they happen. Of course, Menuconfig is probably the easiest of the three, since it explicitly requires bash (Configure, OTOH, works with any /bin/sh), so I don't have to worry much about shell compatibility. I guess it wouldn't hurt to install bash 1.14 somewhere so I can make sure things will work on Red Hat 6.0. An old bash bug bit me once before, in Linux 2.2.19pre.... Peter ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel