My two cents:
I'm in favor of a new description language.
I'm in favor of new tools for processing it.
I'm comfortable with Python as an implementation language. The speed
problems seem to be under control.
It would be nice if either (a) the tools ran with Python 1.5.2 or (b)
some more time elapses and lots more people have Python 2.0 installed.
I think the transition to a new language is so big that anything
controversial about the config files themselves should not be part of
the transition. Just translate the CML1 files directly into CML2.
If someone says "such-and-such is yucky", the defense is: "the CML2
version is less yucky or equally yucky as CML1 was".
After the transition, then have discussions about re-designing the
actual style of the files.
Let the arch maintainers be in charge of their files.
We used to have a lot of problems with arch maintainers writing
stuff that didn't work with all three config programs. Then I
realized "there's never been a spec for this stuff". So I wrote
Documentation/kbuild/config-language.txt, and it became a lot easier for
people to write good Config.in files. Andrzej Krzysztofowicz also went
through all the places in the spec where xconfig had documented silly
restrictions, and fixed them in xconfig.
If there's a good language spec, and good tools that actually report
language errors, arch maintainers and subsystem maintainers can take
care of their own files.
Michael
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
