Hi,
On Thu, 15 Aug 2002, Kai Germaschewski wrote:
> Surely not all conceptual problems are fixable easily, they probably need
> to be done in conjunction with switching to a common parser etc. (Note:
> this switch to a new parser should happen with no change to the config.in
> format or semantics, in order to fit the Linux/Linus way of doing things).
This is where I disagree. Switching the parser and the syntax separately
would mean two big changes, that need to be tested. You actually have to
write two parsers, one that emulates the shell behaviour as exactly as
possible and a second parser that get rids of that again. Doing a single
switch would be far less painful.
There are some corner cases in the current rulebase, which are difficult/
ambiguous for a compiling parser (instead of interpreting). These cases
are mostly in arch/*/config.in files, which were probably never tested
with xconfig.
My converter can convert almost everything, with some small changes to the
input files it should also be able to convert the rest. The resulting
needs some small editing to be completely useable, so this process is not
completely automatic (The reason for this are the recursive dependencies,
which need some small manual fixing).
I tried very hard to make that switch as painless as possible. By
automatically converting the config the rulebase is still almost the same.
Normal users will hardly see a difference (except for xconfig, as that
is reimplemented in QT).
> However, I think it is too late in 2.5 for these kind of big changes.
Most of the work is actually already done, there isn't that much left to
be completely usable. If anyone wants to help, I'd be happy.
bye, Roman
-
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/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:40 EST