lkml.org 
[lkml]   [2002]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote:
>
> The problem here is one should consider, how all these little changes will
> help to solve the big problems. Do they allow to more easily fix the big
> problems or have these changes to be dumped again?

I believe fixing the existing rules within the existing syntax is an exercise
worth doing, and that the results will carry across to whatever extended syntax/
new language/new parsers/whatever will be the long-term solution.

Extending the CML1 syntax now is a fun game but a gamble.

> Most of the suggestions I've seen so far fix problems, which either can be
> either fixed automatically or which don't exists anymore, once we switch
> to a new syntax/parser. That's the reason I ask to understand the whole
> picture, so we can judge whether a change is really necessary or not.

Unlike you, I'm not optimistic that a switch to a new language or even a new
parser for the old language will ever happen.

> I can't give you a mathematical proof, but I tried very hard to keep the
> behaviour the same. Unless I made mistake the rules are almost exactly the
> same. Most of the CML1 rules are usable, there are only very few cases
> which need manual fixing. I can't guarantee that where won't be any
> surprises, but they should be easily fixable in the new system. (Unless
> ESR I don't insist that my rulebase is correct or perfect, so I'm open to
> suggestion/changes. :) )

In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
David Woodhouse gives an idea of what would be necessary to get a new
language+parser accepted. Can you achieve that yet?

> Most of these problems can actually be fixed without syntax changes.

Yes, a great deal of them can be, and those should be done ASAP.

> Something that can't be sanely fixed this way are recursive dependencies,
> which I think are not worth fixing with the old parsers, but which are
> easily fixable with the new syntax.

Indeed, and those are rare corner cases.

> If you want to fix logical errors in the rulebase, they will be more
> easily fixable with the new tools. For the X interface I'm planning some
> debug options, which e.g. allow you to see the complete dependencies of
> every symbol.

Or you could, today, go build gcml2 from source with "make DEBUG=1" and run

cml-check --debug nodes arch/i386/config.in


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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.111 / U:2.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site