[OE-core] should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

On Mon, 9 May 2016, Bruce Ashfield wrote:

> On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>
>         (aside: this is with wind river linux 8 and i dropped bruce a note
>       about it, but i really should keep this stuff on the mailing list.)
>
>         not sure if this is a WRL issue, or more general OE or YP issue, but
>       i was doing a kernel config yesterday, and my SRC_URI included, say,
>       "rday.scc", which incorporated both kernel config fragments and
>       patches, and that worked fine.
>
>         eventually, after massive refactoring, all that was left of that
>       item was some kernel configuration which was already in "rday.cfg", so
>       i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
>       that old "rday.scc" in that directory (with its referent patches),
>       assuming it would be ignored.
>
>         did a clean and configure and got:
>
>         | DEBUG: Executing shell function do_kernel_metadata
>       | ERROR: could not find patch rday.patch, included from
>       .../rday.scc ...
>
>         it *appears* that, even though SRC_URI now refers to (among other
>       things) just "rday.cfg", it looks like the configure step is *still*
>       trying to process "rday.scc", which contains a reference to a now
>       non-existent patch, hence the failure.
>
>         if i just remove (or rename) "rday.scc", then things work fine. is
>       this expected behaviour? is there some reason that if SRC_URI
>       includes, say "derf.cfg", the configuration will automatically look
>       for and try to process "derf.scc"? or am i just doing something silly?
>
>
> There's no automatic inclusions like that. Take a look at your
> meta-series and see if there's an explicit reference to the .scc
> file.
>
> Otherwise, I'll have to try and reproduce it here.

  ah, i just tripped over this again, and here's what's happening. i'm
using overrides to define SRC_URI items in machine-specific
directories, and that works fine, and if i change, say, the .scc or
.cfg files, then do a kernel clean operation and configure again, any
changes i made will be recognized and processed. so far, so good.

  however, i just realized that a related set of SRC_URI files:

  * uio.scc
  * uio.cfg
  * uio.patch

actually apply to *all* my target boards, so i moved those files up
one directory level to be picked up for all builds.

  the SRC_URI reference to this is unchanged, still contains:

SRC_URI += " \
        ... snip ...
        file://uio.scc \
        ... snip ...

but (obviously) the search should *now* find that file in the
general kernel version directory, rather than the board-specific
directory it was in before. not so:

[INFO] Sanitizing .kernel-meta/cfg/mpc8360/kernel_baseline.cfg
[INFO] Sanitizing .kernel-meta/cfg/mpc8360/serial_ucc_uart.cfg
[INFO] Sanitizing .kernel-meta/cfg/uio.cfg
[ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

  it seems that once the configuration process locates the SRC_URI
items the first time, it caches(?) their location, so any *changes*
you make will be picked, but you can't *move* them, even to another
location where they would normally be found based on FILESPATH.

  so ... simple question, what's the command to clear that memory if i
move a SRC_URI item? i did verify that if i *completely* remove the
build directory and start from scratch, then (predictably) it works
fine.

rday

-- 

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

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