From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Wed, 5 Aug 1998 08:29:38 -0400 (EDT)

Driver configuration (dialog, lxdialog and whatnot)

Anyone working on the makefile system check out my WD directory 
in cvs (under the kgicon branch) and see the .configure.  It makes 
some progress toward unifying with the Linux kernel.  It should, 
if I didn't screw up, work on both bourne and POSIX std basic shells;
only tested with bash so far.  The only other utility it
uses is grep.

Running .configure will run using regular dialog, and
will also generate a Config.in file suitable for use with 
the MenuConfig in the Linux tree.  Easiest way to test
this is to ln the WD driver directory into the top level
of the kernel tree and edit arch/<arch>/config.in, go
to the bottom, and duplicate the sound driver entry 
using a variale named of CONFIG_KGI_WD.  You can also
just generate the Config.in file with make Config.in.

Fixable/unimportant problems:

1) move all the configuration to the top of the file,
rather than inside the for loop -- got to figure out how to make
sh interperate the quotes when the menu options are stored

2) I need a tolower() function to downcase a list of object files
from their upcased macro substrings -- but not available
in sh or maybe I should just do an ls | grep -i but that 
puts constraints on choices of filenames -- suggestions?
I'd like to make it so you have as few frivolous mapping tables
to update by hand as possible, and generate the objects to make
as either a default rule or a linux Makefile style set of
conditionals automatically from just the table in .configure.

3) When using dialog the neat folding under when suboptions
that rely on an option isn't available -- need to indent sub-options
or something.

4) Starting work next on a run time link-in function that will allow
optional parts to poke their function table into a driver-global structure
without having to play all sorts of #ifdefs to get symbols
where they belong.  I was just going to autogenerate some C
for this before linking unless someone who actually knows compilers can 
show me some neat ld/nm tricks.  Basically I want to build the object files
only once then be able to link different combos of them together
without symbol conflicts but they need to use each other just the same.

Somewhat more tacky issues:

1) It uses a checklist a) because that's what I personally
want for my driver and b) because I don't seem to remember seeing
a radio list anywhere in the kernel config menus so I don't know if they
are considered depricated somehow.  If radio list is desired,
someone else will have to write it.

2) What do we do with the "make config" target -- confusing if
a person cd's into the driver directory and tries to configure
from there rather than with the kernel scripts, but needed for 
when driver not in kernel source tree.  Detecting the kernel
tree might end up being a crummy idea...

3) Can we gracefully swing getting Config.in generated automatically
during kernel config, or should we just provide a run-off of
./configure when sending patches to mainstream kernel?

4a) Nesting of dependent sub-options should be implemented; one-deep
should be easy.  Do we need anything more complex? (e.g. x depends on y
being present but also depends on z with no dependence between y and z)

4b) Kernel will let you compile part of the bugger as in-kernel
and other fragments as modules.

--
Brian S. Julin