[Sam Ravnborg] > Where comes the requirement that we shall keep the existing shell > based config parsers?
I don't make that argument - mconfig is the superior solution by far - but it is certainly the path of least resistance. As pertains to CONFIG_EXPERIMENTAL and " (EXPERIMENTAL)", it *is* possible to add such a feature to the shell-based parsers by changing the syntax slightly - specifically to lose the '$' on dependencies. Changing the syntax *does* have ramifications when it means adapting three separate parsers, but it can be done. > Remembering the CML2 war there were no serious objections about > shifting away from shell based parsers (but certainly a lot about > the alternative selected). It would have been a big change and a big flag day, and among other problems, the rulebase conversion issue was handled wrong. Eric refused to start from a 1-1 equivalent rulebase, preferring to tweak the rulebase as he went along - partly just to fix bugs, partly to show off his new capabilities. Unfortunately, without the apples-to-apples comparison, many people distrusted the new system, superior though it was in many ways. This is the primary lesson to be learned from CML2. Anyone trying to redesign a subsystem such as the kernel config system needs to keep it in mind. (Yes, I know from the rest of your message that you learned it.) Peter ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
