Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Christoph Hellwig <[e-mail]>:
> There is a CML1 language specification, as written down in a file, namely
> Documentation/kbuild/config-language.txt in the kernel tree.

A specification which, according to its author, is incomplete.

> There is one tool (mconfig) which has a yacc-parser that implements that
> specification completly, and some horrid ugly scripts in the tree that
> parse them in a more or less working way.  There also are a number of
> other tools I don't know to much about that understand the language as
> well.

N separate implementations means N dialects and N**2 compatibility problems.
Nicer just to have *one* parser, *one* compiler, and *one* service class that
supports several thin front-end layers, yes?  No?
 
> All of these tools just require the runtime contained in the LSB and no
> funky additional script languages.  Also none needs a binary intermediate
> representation of the config.

I quote Linus at the 2.5 kernel summit: "Python is not an issue."
Unless and until he changes his mind about that, waving around this
kind of argument is likely to do your case more harm than good.

If you want to re-open the case for saving CML1, you'd be better off
demonstrating how CML1 can be used to (a) automatically do implied 
side-effects when a symbol is changed, (b) guarantee that the user
cannot generate a configuration that violates stated invariants, and 
(c) unify the configuration tree so that the equivalents of arch/*
files never suffer from lag or skew when an architecture-independent
feature is added to the kernel.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491