[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
