Tom Rini <[EMAIL PROTECTED]>:
> Strictly stated implication for strictly stated implication?
Can't do that, either. One major reason is the single-apex menu tree.
Another is that the old language didn't carry enough information to
do side-effect forcing properly.
> > What invariant or behavior are you trying to preserve with "no additional
> > restrictions"? Most of the additional restrictions are bus guards, so that
> > (for example) users won't see EISA questions on a non-EISA system. Is this
> > a bad thing?
>
> Well, if there wasn't an EISA guard for CML1, there should't be for CML2
> _yet_. Why? It's either an intentional feature (it's actually EISA and
> some wierd bus from {arm,ppc,cris,other}) or it's a bug that should be
> submitted seperately so someone can pop up and say it's wrong or not.
>
> There's an underlying concern that if it's not a rather strict
> translation of the current rules, there's bugs, and people don't want to
> fix bugs that don't exist in the current system.
Well...all I can say to this is that I have beta-testers regularly sending
me rulesfile fixes, but they're all pretty minor stuff. If the logical
mapping between old and news spec were seriously broken, I would not
be able to avoid knowing it.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
