Re: CML2 Transition experiences

[Eric S. Raymond]

jeff millar <[e-mail]>:
> 1. If I install CML2 and go directly to "make xconfig", it deduces it needs
> to set top level options because some of the low level options are set.  For
> example SCSI enabled because some SCSI device is set or hot plug because
> PCMCIA is set...because some PCMCIA device is set.  The _problem_ is...none
> of these options were set in the CML1 generated .config file... and it
> _extremely_ tedious to use xconfig to clear out all the cruft.
> 
> A much better (but not yet right) way is to use "make ttyconfig" to quickly
> generate config.out from .config  relatively fewer errors and ability to say
> no at a top level and cause all the lower level stuff to go away.  make
> ttyconfig seems to parse the .config file in a different (and better) order.

I'm finding this report very puzzling.  Both front ends parse the
.config in exactly the same order.  In fact, it's done by the same
code.
 
> Suggestion:  On the first pass of CML2 processing through .config, before
> first config.out created, trust the top level setting and ignore lower level
> settings if top setting off.

Because of the order tree traversal is done, I think ttyconfig should give
you the effect you want.
 
> 2. So after some playing around, I want to go back to CML1.  But the .config
> generated by CML2 is not compatible.  I don't know if it's supposed to be
> but there's lots of problems.

The config.out isn't exactly compatible; it has explicit CONFIG_FOO=n settings
in it.  The .config file generated from that by configtrans should be, however;
if it's not that's a bug.  Can you send me your "incompatible" .config so 
I can see the problems?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.