Linus Torvalds <[EMAIL PROTECTED]>:
> So the config file format could be something that includes the docs, and
> you could do something like
>
> find . -name '*.cf' -exec grep '^+' {} \; > Configure.help
>
> for old tools, and nw tools would just automatically get the docs from the
> same place they get the config info.
OK. Background, for anyone who doesn't know this: the equivalent of
Configure.help in CML2 is the symbols.cml file. It's actually generated
fat CML2 installation time from Configure.help.
Here's what a sample entry looks like in Configure.help form:
Support the foo feature
CONFIG_FOO
This is a sample help entry.
Here's the same entry in CML2 format:
FOO "Support the foo feature" text
This is a sample help entry.
.
Now. It would be dead easy to split symbols.cml into bunch of little
files and distribute them through the source tree. It would be just as
easy to write a script to reassemble Configure.help, but there won't be
any reason to do it. Once CML2 goes in, nothing will use Configure.help
> The current Configure.help is 25k _lines_, and over a megabyte in size. I
> would never consider that good taste in programming, why should I consider
> it good in documentation?
Um...because the cases aren't parallel?
What makes megabyte-large blocks of code bad is that they tend to be
tangled messes with unmaintainable reference and control structures.
Configure.help isn't; the entries are atoms that don't interact with
each other.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
-- T.S. Eliot
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
