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. _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
