[]
[]
[]
No. Not another semi-newbie and/or semi-halfway done job, please.
I'm pretty sure, that Linus is proposing that only after manual
editing of/looking into the `.config' after `make oldconfig`.
Before you will consider anything, please, check recent LKML (kbuild
rewrite) and kbuild-devel(years 2001-2002) archives (assuming, you have
experience with any build/conf things).
Today's kconfig was proposed and accepted in a very unpleasant
circumstances, has very poor design, development and no working
alternative (for 5+ years now).
The basics, i'm trying to put into design of the new kconfig, as part of
my kbuild (already described a bit)/kconfig rewrite are:
* flexible configuration development(kdevs) and process(kusers)
+ shell-like[0] (not like CML1, which is just shell) scripting, allowing
to extend easily (if there is no one available) capabilities,
config values or actions for particular sub-system or compilation
unit,
[0] if somebody would like to see *a* shell-like scripting:
ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant
+ duplex travelling, multi- looking at/changing of config items,
+ flexible, yet built-able, connections in dependency chain (tree,
graph, whatever);
* resulting config file capable of producing exact config results of the
build on any other setup
(e.g. no ARCH=, CROSS_*, *_FLAGS *kbuild* things);
* checking tool for particular config patterns (for bug reports)
* system itself must be done with minimum requirements for C libraries
(no ncurses) and tools (no `perl`, no `python`, no `make`).
Fsck it. All must be done by a machine with maximum comfort of users (not
particularly humans), even for those, who like to edit config like so:
`sed -i 's/SYSFS=y/SYSFS="please, NO!!!"/' .config`
--
-o--=O`C
#oo'L O
<___=E M
-
