Keith Owens <[EMAIL PROTECTED]>:
> The main visibility problem I reported against cml2 1.9.1 has been
> fixed in 1.9.3, but there is still one peculiarity.
>
> # rm .config config.out rules.out
> # yes '' | make oldconfig
>
> Although make oldconfig only asks about
> BLUEZ: Bluetooth subsystem support < > (NEW)?:
> the generated config.out contains extra BLUEZ sub options.
>
> # grep BLUEZ config.out
> config.out:CONFIG_BLUEZ=n
> config.out:CONFIG_BLUEZ_L2CAP=n
> config.out:CONFIG_BLUEZ_HCIUSB=n
> config.out:CONFIG_BLUEZ_HCIUART=n
> config.out:CONFIG_BLUEZ_HCIVHCI=n
>
> Doing a second oldconfig gets rid of the spurious entries.
> # make oldconfig
> # grep BLUEZ config.out
> config.out:CONFIG_BLUEZ=n
>
> Any chance of generating a consistent config on the first pass? It
> worries me that a second pass is required to get a stable config.
I already explained this. First time around, BLUEZ is not frozen, so the
dependent symbols get saved.
Giacomo Catenazzi argues (I think correctly) that the most important property
of `make oldconfig' is that you *never* get asked questions about old symbols.
The only way to accomplish this is to read in the old config frozen.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
The two pillars of `political correctness' are,
a) willful ignorance, and
b) a steadfast refusal to face the truth
-- George MacDonald Fraser
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
