On Thu, 2018-08-02 at 10:55 +0800, Anuj Mittal wrote: > On 08/02/2018 07:30 AM, Alejandro Enedino Hernandez Samaniego wrote: > > Hey Anuj, > > > > > > On 08/01/2018 04:25 AM, Anuj Mittal wrote: > > > On 07/31/2018 05:21 AM, Jaewon Lee wrote: > > > > When using a recipe space kernel-meta, scc files are added > > > > through > > > > SRC_URI, but they may include corresponding kernel fragments > > > > that are > > > > not necessarily in SRC_URI. > > > > > > > > For bitbake, this is not a problem because the kernel-yocto > > > > class adds > > > > the path where the .scc file was found to includes which > > > > consequentially > > > > makes the .cfg file available to the kernel build. > > > > > > > > However, when using devtool, only files specified in SRC_URI > > > > are copied > > > > to oe-local-files in devtool's workspace. So if the cfg file is > > > > not in > > > > SRC_URI, it won't be copied, causing a kernel build failure > > > > when trying > > > > to find it. > > > > > > > > This fix parses local .scc files in SRC_URI, copies the > > > > corresponding .cfg > > > > file to devtool's workdir, and also adds it to local_files so > > > > it is > > > > available when doing a devtool build for the kernel. > > > > > > > > [YOCTO #12858] > > > > > > > > Signed-off-by: Jaewon Lee <[email protected]> > > > > Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@ > > > > xilinx.com> > > > > --- > > > > meta/classes/devtool-source.bbclass | 12 ++++++++++++ > > > > 1 file changed, 12 insertions(+) > > > > > > > > diff --git a/meta/classes/devtool-source.bbclass > > > > b/meta/classes/devtool-source.bbclass > > > > index 56882a4..c70fea2 100644 > > > > --- a/meta/classes/devtool-source.bbclass > > > > +++ b/meta/classes/devtool-source.bbclass > > > > @@ -90,11 +90,23 @@ python devtool_post_unpack() { > > > > fname in files]) > > > > return ret > > > > > > > > + is_kernel_yocto = bb.data.inherits_class('kernel-yocto', > > > > d) > > > > # Move local source files into separate subdir > > > > recipe_patches = [os.path.basename(patch) for patch in > > > > oe.recipeutils.get_recipe_patches(d)] > > > > local_files = oe.recipeutils.get_recipe_local_files(d) > > > > > > > > + if is_kernel_yocto: > > > > + for key in local_files.copy(): > > > > + if key.endswith('scc'): > > > > + sccfile = open(local_files[key], 'r') > > > > + for l in sccfile: > > > > + line = l.split() > > > > + if line and line[0] == 'kconf' and line[- > > > > 1].endswith('.cfg'): > > > > + local_files[line[-1]] = > > > > os.path.join(os.path.dirname(local_files[key]), line[-1]) > > > > + shutil.copy2(os.path.join(os.path.dirname(local_ > > > > files[key]), line[-1]), workdir) > > > > + sccfile.close() > > > > + > > > > > > Would the patches included in these .scc files also need to be > > > handled > > > in the same way? Would this also work if there are other scc > > > files > > > included in a scc file? > > > > Yes, I believe that the same mechanism should be used for patch > > files as > > well, > > basically anything that may be needed to build but that its not > > necessarily > > explicitly listed on SRC_URI. > > > > I believe it will work for other scc files and it doesnt have to > > be > > recursive, > > because while cfg files arent required to be in SRC_URI , scc files > > ARE > > required > > to be SRC_URI, which means that this will eventually find the other > > scc > > file on the list > > I don't think they are required to be specified except for the top > level > one. At least, when I test it, I see problems. kernel-tools spp > script > parses them recursively and looks for a nested scc even if it is not > specified as part of SRC_URI. That is how the top level sccs from > kernel-cache are parsed too. Can you give it a try please?
What would be really great here would be some test cases in the qa framework! It'd be a good way to both illustrate the problems and then test we've fixed it and that it stays fixed. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
