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.
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.
But maybe I'm not quite understanding your question, if you can
send along an example, that might help.
Cheers,
Bruce
Cheers,
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
