On 08/03/2018 04:55 AM, Alejandro Enedino Hernandez Samaniego wrote: > We can give it a try but do you have a specific example of how it fails > for you? > Because I know theres lots of nested sccs on the yocto kernel cache, but > in that case > it wouldn't be a problem since this bug is specifically introduced by > devtool when it > copies local files from SRC_URI to a oe-local-files directory, it misses > the corresponding cfg files (or patch files) > since they're not listed in SRC_URI and it fails to build, in the case > of the yocto kernel cache, it > does not contain local files, so they wont be moved hence why it > wouldn't be an issue. > > From the kernel dev manual: > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#recipe-space-metadata > : > It is only necessary to specify the |.scc| files on the |SRC_URI| > <http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRC_URI>.
You are ignoring the line right next to it: "BitBake parses them and fetches any files referenced in the .scc files by the include, patch, or kconf commands." All files specified using 'include' will be parsed too even if they are not in SRC_URI and this includes other scc files. This change is good because it fixes something that is definitely broken. My suggestion was meant to improve it further. I had provided the test case in my reply to original patch. And, I just tested it again using this change applied and I do see errors when using a nested scc. Here it is again: │ ├── linux │ │ ├── linux-intel │ │ │ ├── abc.scc │ │ │ ├── def.scc abc.scc only includes def.scc. And, def.scc includes a patch. SRC_URI includes only abc.scc. > > It specifies that only the scc files need to be on SRC_URI, which is why > I'm saying the script > will eventually run into them from the list. > > I want to be clear that I'm not against doing this recursively, I just > want to understand your testcase better. I think if you'd not like to consider this use case as part of this change, that should also be fine. But, do consider adding a new bug in that case. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
