Subject: Re: config defflag filename
To: None <email@example.com>
From: john heasley <firstname.lastname@example.org>
Date: 06/23/2003 12:46:56
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.