[OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

[Richard Purdie]

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 <jaewon.lee at xilinx.com>
> > > > 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