Re: [patch] config language dep_* enhancements

Roman Zippel (zippel@linux-m68k.org)
Wed, 14 Aug 2002 13:40:48 +0200 (CEST)


Hi,

On Tue, 13 Aug 2002, Peter Samuelson wrote:

> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an alternative
> syntax for 'if' statements which doesn't look like test(1). More
> about that in a separate message.

That doesn't solve any of the more fundamental problems.
1) We still have 3 config parsers, which produce slightly different
.config files.
2) To integrate a new driver, you have to touch at least 3 files:
Config.in, Config.help, Makefile. Properly configuring and building a
driver outside of the tree is painful to impossible.

I'm not against fixing the bugs in the config scripts or adding some
small extensions, but if you want to "mutate" the language into something
different, I really hope you have a good plan for that.
The problems are really not simple, the current config language is very
limited, which also limits a bit the current error sources. As soon as you
add new features, you need to add better error checking, which will be
very painful in pure shell and keeping it consistent between multiple
parsers will also be interesting.
It's not the same problem area as with the build system. There we only
have a single Rules.make file. Normal users don't need to care much about
it. make was actually designed to build applications. The build system can
rely on correct information from the config system.
The build system was fixable within the capabilities of make, but the
config system involves a lot more complex system of various scripts and
programs. If you some great ideas to fix all the problems, I'd really like
to hear them.

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/