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

[Robert P. J. Day]

  (i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

  while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

  i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards,
and i also extended MACHINEOVERRIDES to define a common grouping for
two of those boards. and here's the problem.

  i have files:

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

that used to apply to the two common boards, but should now apply to
all three, for all kernels.  so i used to have the directory
structure:

  linux-windriver/
    common/               (represents the 2 out of 3 related boards)
      uio.scc
      uio.cfg
      uio.patch

and the uio stuff was located just fine when building for either of
the two target boards for which "common" was my extension to
MACHINEOVERRIDES.

  now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

  linux-windriver/
    uio.scc
    uio.cfg
    uio.patch
    common/
      uio.scc
      uio.cfg
      uio.patch

and all three boards can now build. however, when i went to get rid of
the redundant stuff and reduce it to:

  linux-windriver/
    uio.scc
    uio.cfg
    uio.patch
    common/
      ... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards
fail to process the kernel fragment uio.cfg. having moved that
completely common uio content out of the subdirectory and right under
linux-windriver now breaks the boards for which there is still a
subdirectory, for no reason that i can see.

  it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no
longer look elsewhere, even above for more generically appropriate
content.

  am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top
level of one of these directories.

  anyone seen anything like this?

rday

-- 

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

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