[yocto] is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

  ok, i've narrowed this down to a fairly trivial case, so allow me to
describe it. first, in my kernel recipes directory structure, i have
subdirectories:

linux-windriver-3.14/
linux-windriver-4.1/
linux-windriver/

and that last directory contains:

$ tree linux-windriver
linux-windriver
├── mxeiii            (target board in question)
│   ├── mm.patch
│   └── mm.scc
├── ssd_sil.cfg
├── ssd_sil.patch
├── ssd_sil.scc
├── uio.cfg
├── uio.patch
└── uio.scc

  so, that directory contains two SRC_URI items *immediately*
underneath, and one more further under mxeiii/, which is my target
board.

  first experiment:

SRC_URI += " \
        file://new_board.scc \           (adding this has no effect)
        file://uio.scc \
        file://ssd_sil.scc \
"

so (other than new_board.scc), i am processing only .scc files
immediately under linux-windriver/. and that works fine:

  $ make linux-windriver.configure

and i can list
bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/ssd_sil.cfg
[INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

so far, so good.

  now, let's extend SRC_URI to pick up one more item, but this one
from the lower mxeiii/ directory:

SRC_URI += " \
        file://new_board.scc \
        file://uio.scc \
        file://ssd_sil.scc \
        file://mm.scc \              <----- new item
"

after a clean and configure:


ERROR: Function failed: do_kernel_configme (log file is located at
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Logfile of failure stored in:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821
Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| NOTE: kernel configme
| [INFO] Configuring target/machine combo: "standard/mxeiii"
| ERROR: could not sanitize configuration fragments
|    errors are logged in
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log
| WARNING:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/run.do_kernel_configme.11821:1
exit 1 from
|   configme ${configmeflags} --reconfig --output
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/linux-mxeiii-standard-build
standard mxeiii
| ERROR: Function failed: do_kernel_configme (log file is located at
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Task 6
(/home/rpjday/Builds/swe/8/m/layers/wr-kernel/recipes-kernel/linux/linux-windriver_4.1.bb,
do_kernel_configme) failed with exit code '1'

and here's the config.log file from that attempt:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/uio.cfg
[ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

Notice how this differs from the first two lines from the successful
configure before:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg

The pattern appears to be that, once the SRC_URI search is forced to
enter that mxeiii/ subdirectory to find something, the search for
previously found SRC_URI items gets totally borked.

I've tried this several times, and the behaviour is consistent.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================