6658 2014-08-24 17:33:35 +0000 devtool: enable kernel development 2016-07-27 21:47:00 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.7 All Multiple RESOLVED FIXED Medium+ enhancement 2.1 M3 6653 1 bluelightning markus.lehtonen alexandru.c.georgescu bruce.ashfield dvhart francisco.j.pedraza.gonzalez meta.mr.watcher meta.watcher francisco.j.pedraza.gonzalez --- --- Yes (doc changes required) oldest_to_newest 45238 0 bluelightning 2014-08-24 17:33:35 +0000 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.) 50429 1 markus.lehtonen 2015-04-20 19:13:26 +0000 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? 50445 2 bruce.ashfield 2015-04-21 14:16:16 +0000 (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. 56993 3 markus.lehtonen 2015-12-03 14:08:34 +0000 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. 58331 4 markus.lehtonen 2016-01-29 08:42:33 +0000 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