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

[Robert P. J. Day]

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

rday

-- 

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

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