Hi Bruce, On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfi...@windriver.com> wrote: > On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote: >> >> Today I have spent quite a while trying to figure how KERNEL_FEATURES >> works and why some of the things I pass in my configuration fragment >> are not getting enabled. >> >> It turned out that some of the options no longer existed and some had >> been renamed. > > > Do you have an example ? We try and not rename or remove public facing > configuration fragments, and hide the changing CONFIG_* values behind > the fragment names.
Here is what I was doing first: CONFIG_SND_OMAP_SOC=n CONFIG_SND_OMAP_SOC_MCBSP=n CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n CONFIG_SND_SOC_TWL4030=n CONFIG_SND_AM335X_SOC_EVM=m CONFIG_SND_AM33XX_SOC=m CONFIG_SND_DAVINCI_SOC_MCASP=m CONFIG_SND_HRTIMER=m This is resulted in disabled options propagating as expected and CONFIG_SND_HRTIMER worked as well. The rest, however didn't. It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be a way to verify whether this existed or not. It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it comes first. This is a working set: CONFIG_SND_OMAP_SOC=m CONFIG_SND_OMAP_SOC_MCBSP=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_SOC_TWL4030=m CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_AM33XX_SOC_EVM=m CONFIG_SND_DAVINCI_SOC_MCASP=m CONFIG_SND_HRTIMER=m >> The question is really why would this not get detected by >> kernel_configcheck or any other step? >> >> I'm guessing this might be the case of how kconfig works, perhaps... >> So I wonder whether anyone have looked into how we could actually get >> the feature dependency graph from kconfig to bitbake or at least some >> sort of helper tool? Perhaps parsing kconfig manifests in Python would >> be a starting point... > > > There have been many efforts are changing, writing and processing > Kconfig constructs in other languages .. they all end up being > pretty much a re-implementation of Kconfig, and hence a big effort > that needs to be continuously maintained over time .. also a big > effort. I basically think that we could do something better then blindly throwing a set of options without verifying it. The reason I mentioned Python was that I though of sharing Kconfig's dependency graph with bitbake and thereby detecting errors like the above. As a user, this is what I'd love to see: Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?) Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have specified doesn't exist. (Nothing similar exists) Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have specified depends on CONFIG_SND_DAVINCI_SOC. I will enable CONFIG_SND_DAVINCI_SOC as a module for you. Hope this makes more sense. Cheers, -- Ilya -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto