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.
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.
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.
Suggestion: Save your .config before you play with this stuff.
Bottom line: looks promising but I still haven't gotten a good compile from
it, yet.
jeff
jeff millar <[email protected]>:
> 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.