No, it's not.
Nobody wishes more than me that this had been possible, as the
parallel CML2 rulebase has been an energy sink you wouldn't believe --
it has eaten more of my time than any other single project I've been
involved with in the last two years.
Unfortunately, the syntax of CML1 is rebarbative, and its imperative
semantics cannot be mechanically translated to CML2's declarative
semantics by any means I'm aware of.
> After all, the only way for the merge of CML2 to be acceptable is to merge
> the tools _first_, without changing the resulting behaviour of the config
> rules, and then to make behavioural changes in later versions.
That's a different issue. The CML2 rulebase does produce behavior
substantially like that of the CML1 rulebase in most respects. There
are divergences due to the single-apex tree, but nothing that has caused
any of the beta testers a problem. I sweated blood to make it so.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>"Are we to understand," asked the judge, "that you hold your own interests above the interests of the public?"
"I hold that such a question can never arise except in a society of cannibals." -- Ayn Rand - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/