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

[Anuj Mittal <anuj.mittal@intel.com>]

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@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?

Thanks,

Anuj