Mon, Jun 16, 2003 at 11:17:56AM -0700, john heasley:
> According to config(9), defflag without a filename causes a command-line
> macro to be defined.  For example, cc ... -DFOO.  But, what really happens
> is a command-line macro is defined _and_ an option file is created (based
> on the lowercase of the option name), such as opt_foo.h.
> 
> config could be changed to match the manpage, but will result in a bit of
> fall-out since there are several options (for various archs) defined with
> defflag that lack a filename.  I did not check if those files are actually
> used in any of these cases (except sparc:BLINK, where the file is used)
> and defparam (and the deprecated defopt) likely act similarly.
> 
> Defining an option in a kernel config that is not defined with defflag,
> does result in a command-line macro, but then config does not perform
> syntax checking.
> 
> So, assuming the extra opt_*.h file is no big deal (I don't think it is),
> just fixing the man page for config(9) seems appropriate.  Perhaps I'm
> missing some history, such as a transition plan to make the filename
> required.  Opinions?

FYI.  From a brief discussion with Jason Thorpe and Martin Husemann, the
approach we'll take is:

1) Follow the original intent of config(8) and make defflag FOO (and
   defparam), with or without a filename paramenter, not generate
   -D anymore, and fix the man page accordingly.

2) Check the tree for *.files files with options affected by the change and
   build a sorted list of options and their opt_*.h filenames; then check
   all uses of the FOO define if the source includes opt_foo.h, and if not
   fix it.  Martin has already done this part.