> Seriously, why would it need to be parsable from sh at all? Can
> include a flex/bison grammar (pre flexed/bisoned even, though I doubt
> this would at all be necessary, I would guess that flex and bison are
> much more ubiquitous on machines with development tools installed than
> perl would be.) with the rest of the kernel sources, that would get
Over the last two days I've got something sort of like what you are
talking about sort of working. Basically it is a flex/bison parser which
parses a configuration definition file which is itself piped through
cpp. The library/programs themselves are all written in c. I figured
that if you will compile the kernel, you will most likely have a c
compiler ;).
This "compilation" stage outputs a parent/sibling tree (binary format
though) to stdout which can then be saved or whatever. Two functions are
available to read or write the entire tree, and I've already created two
quick but not very functional hacks, one which reads this binary file and
outputs a configuration header, and the other which reads the binary file
and actually outputs an sh script to use the "dialog" program to query
the user about which options to have, and the writes a configuration
header. A tty one could easily be created as well (also necessary)...
Does anyone know of a higher level ncurses based UI library in C?
Basically the configuring program works on and saves the values in this
binary file, and a genconfig program is used to take that binary file
and create a header file (another method is to use something like the
sh-builder approach though). I was wondering, though, if it might be
better to produce a text file instead of a binary file, in a format
similar that of the original file (excluding comments and formatting),
but it might be larger.
A typical general configuration file to feed the parser might
look something like this, where the "implies" keyword means it requires
another section node.
/* an example */
section net_devs "network devices"
implies net_sup, sysv_ipc
{
helptext "Configuration of various network devices." &
"More help text.";
bool ne2000
{
helptext "Standard ne2000 Compatibles";
falsetext "#undef CONFIG_NE2000";
truetext "#define CONFIG_NE2000";
}
section net_more "Subsection"
{
helptext "more stuff here";
}
}
Since it is piped through cpp, macros can be used not to mention c-style
commenting and include files, also emacs c-mode ;-).
I am only playing with it and do not know if it is worth pursuing. I am
not sure about how to handle a few things, how many section
"descriptors" should there be? The keyword "implies" could mean that it
"expects" another section to already be included and if it is not to
query the user for it's inclusion. There could be "levels" of help...
If anyone has any ideas or suggestions they would be appreciated, there
are many things to consider or to and I really don't know too much about
"what's best." If anything were to be serious, it would have to be more
defined and slimmed down to the minimum parts.
One thing that could be done is to add an optional "file" keyword to the
body of section, allowing for more specific configuration headers and
less compiling. (I guess only the files affected need be generated)
Andrew Veliath <drewvel@ayrton.eideti.com>
http://ayrton.eideti.com/~drewvel