On Wed, 12 Dec 2001 11:57:33 +0100, Giacomo Catenazzi <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> OUCH! The output from make menuconfig has significantly more options >> than make oldconfig when given exactly the same input. I thought one >> of the selling points for CML2 was different front ends but with >> identical back end processing. I don't like the way that the resulting >> config varies when fed to different front ends. > >There are two policy to what symbols should be written: >1) not visible symbols should not be written in final config.out >2) all symbols should be written. > >CML1 use policy 1). CML2 actually seem to use also 1), >but with few exceptions (previously visible symbols,...), >but it is not clear what is the right behaviour. > >What policy we should adopt? >The second proposal (which I don't like), seems to be simpler >and cleaner, and with kbuild-2.5 it should be no problem with >extra symbols set to 'no'. > >Could we move to the second proposal?
Disagree. The values of non-visible symbols are not validated. When you write out all symbols, the invisible symbols can have invalid values. When the guard symbol is activated the previously invisible symbols become visible, they pick up the invalid data from the config and start complaining. I like the way that CML1 pops up all the previously hidden symbols when you activate the guard symbol, it tells you immediately what you just did. When invisible symbols are written out, only some of the guarded symbols will show up as new, others will have semi-random values from previous configs and will show up as old, that is inconsistent processing. This particularly affects make oldconfig. IMHO the only correct method is to write out only the visible symbols. Also I suspect that part of the CML2 problem is inconsistent state about which symbols are visible or not, caused by the slightly different constraints of the front ends. If that is the case, the fix is obvious. Once an acceptable config has been entered and has passed all the rules, delete all visibility state from the config and recalculate the visbility state of each symbol from scratch. That is probably the only way to guarantee identical output irrespective of front end variations. _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
