[Eric S. Raymond] > I'm not ignoring your point at all. But saying "don't make policy > changes" is easy to do, knowing where the boundary between "policy" > and "design bugs" falls is rather harder. I'm not going to refrain > from fixing design bugs because some people might think they are > policy -- in many cases there was never any decision or thought about > the alleged "policy".
Good points. But Eric, people keep saying this and you keep rebuffing it. I know there is a strong temptation, having fixed the underlying structural weaknesses with configuration, to fix all those rulebase bugs which were difficult or impossible to deal with in the old system. And I support this - I personally don't think you should be necessarily standing still. But, aside from python2 (and the autoconfig red herring from last month), this now seems to be THE beef about CML2. I know it would be an additional drain on your time (or someone else's, I suppose - anyone? anyone?) but you might consider maintaining another rulebase in parallel with your current one: a rulebase that faithfully duplicates, bug-for-bug, the current Config.in statements. That would shut up some of the last remaining critics of CML2. The people who think python2 is too onerous (and yes, I admit, I don't like that requirement either) ... well, there's not much you *can* do about that point. You've already said going back to 1.5, while easy on the surface, isn't really viable, for subtler reasons. If I had a few more than 24 hours in my day I might take up the CML1-Compatible CML2 Rulebase Project ... but alas, I don't (and my time management skills suck so I seem to have less free time for this sort of thing than I should). Anyone want to pitch in here? Really, there's no reason Eric should have to go it alone......... (Aside: it's possible that the compatible rulebase could be generated by a script. I know they're different paradigms, but the point here is *not* to take advantage of additional CML2 functionality.) Peter _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
