> I don't actually disagree that this specific case is a bug in the
> Config.in file, however it annoys me to see over and over again how
> the Config.in files are changed to get around stupidities in the menu
> based config tools.
It doesn't make me happy either.
> Except that it requires that the people who write the patches actually
> use these tools. There is no way I am going to waste time running
> menuconfig/xconfig before shipping something.
These are supported features and I can't remove them from the
kernel (much as I would like to simply kill xconfig).
The best I know how to do is write a common front end with a static
parser. Then you would automatically get checking even with 'make config'.
> I am not arguing against the fact that a required keyword was missing,
> that _is_ a bug. What I am pointing out is that it always seem to be
> the menu based config tools that break things.
Go get 2.3.18ac9 and *run* "make config" on it and tell me if it works.
I haven't, but I'd be really surprised if it did. Bash doesn't like
missing "then" keywords either.
> If it is going to break the readability of the current Config.in,
> .config and defconfig files then no thanks.
Ok, I don't need to talk to you any more, because even though lots of
your criticism is valid, you haven't spent five minutes reading the
*existing* documentation in Documentation/kbuild/config-language.txt,
let alone looking at my new code.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/