Hi,
On Fri, 16 Aug 2002, Peter Samuelson wrote:
> 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.
I haven't given up yet. :)
> * The current 'if' statement is really ugly and unintuitive,
Is that problem really that big? I think most kernel hackers can deal with
that. Of course this needs fixing, but there are other more important
problems. Actually this one of the simple problems my converter can solve
automatically.
> * 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.
Many people don't have to think about this, because most dependencies are
quite simple. (This problem also becomes irrelevant with the new parser.)
> 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.
It's not really the same. CML2 and kbuild 2.5 both have the same problem -
the "fix all problems at once + a little bit more" syndrome.
Kai instead concentrated on the most important problem - correct
dependencies. Most of the surgery was concentrated on Rules.make and the
changes to the Makefiles were not only cleanups, but helped to fix the
main problem.
What is now the main problem with the config system? The shell based
dependency syntax? It's an annoying problem, but not really that serious.
The biggest problem are still two completely different parsers, which
limit the language syntax. To solve this problem we need to drop one or
both parsers. The shell parsers are the cause of the language
limitations, which force us to keep the syntax imperative and makes it
difficult to add new information. Nobody wants to touch xconfig.
So the only solution I see is to drop both parsers. You can evolutionize
as much as you want, but it doesn't help to solve the main problem. On the
other hand as soon as the main problem is solved, lots of the small
problems can be solved for free.
> 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.
Try to make a list of all the problems, try to prioritize them and
estimate the needed changes to rulebase and parsers. Now try to minimize
the amount of work needed to solve all the problems.
You currently ignore the xconfig problem, which seem to make most of the
problems easily solvable, but we possibly end up with a broken X
interface. The new parser with the new frontends is the largest amount of
the work, which needs to be done anyway and once it's done, it will solve
a lot of the small problems automatically.
I don't think that making multiple large syntax changes is a good idea.
Learning a new syntax is already annoying, but having to do it multiple
times will really annoy a lot of people. Making some small controlled
extensions or small rulebase fixes are not the problem, but you should
really try to avoid changes which require massive changes to all config
files.
bye, Roman
-------------------------------------------------------
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
