Ensure we have whatever we need in place to support kernel development using the tool outlined in bug 6653. This includes but may not be limited to: * Ensure that externalsrc works properly for the kernel * Ensure that the appropriate tasks are called when building * Reduce as much as possible the time taken to build after changes, e.g. ensure compilation is incremental; possibly eliminate module building where appropriate * Allow access to menuconfig for the kernel (and other recipes that inherit cml1) (This may obviate bug 2658.)
Handling the kernel configuration nicely is possibly the trickiest part. There are multiple "levels" of support that could be enabled: 1. Changing config in B (builddir), e.g. via menuconfig 2. Store/commit full config in srctree and use that for building 3. Support modifying config via the meta branch Any opinions? Maybe a separate bug about the config handling would be in order?
(In reply to comment #1) > Handling the kernel configuration nicely is possibly the trickiest part. > There are multiple "levels" of support that could be enabled: > 1. Changing config in B (builddir), e.g. via menuconfig > 2. Store/commit full config in srctree and use that for building > 3. Support modifying config via the meta branch > > Any opinions? Maybe a separate bug about the config handling would be in > order? Cases #1 and #2 make sense if you find a sane starting configuration. For #3, it would be the meta branch, or just use recipe space configuration fragments (since they are treated the same by the code). An easier starting point would be recipe space fragments. In the end, it would be a good idea to ensure that whatever the tools support for configuration that we end up producing consistent: - base configuration - incremental fragments We can do that for any of the cases above, by saving the original config, and either directly producing the fragment, or by diffing against the original. Since this model familiarizes developers with configuration fragments, and they are something that can easily be reviewed and made part of a permanent build.
This bug has been a bit forgotten. All the basic support should be there, now, except for the kernel config handling. I just sent a devtool patch that makes devtool copy kernel .config to the srctree when doing 'extract' operation: http://lists.openembedded.org/pipermail/openembedded-core/2015-December/113693.html What do you think, is this a sufficient way to store a base configuration? With this 'devtool update-recipe' could diff the effective configuration in ${S} against this base and add any changes as one monolithic config fragment to the recipe.
I'm closing this now as the basic kernel support has been merged. There is a separate related bug kernel about kernel config handling: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8999 Please re-open if you disagree