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

[Robert P. J. Day]

On Wed, 20 Apr 2016, Bruce Ashfield wrote:

>
>
> On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>       On Wed, 20 Apr 2016, Bruce Ashfield wrote:
>
>       > You haven't supplied your SRC_URI in the question ... what does it
>       > look like ?
>       >
>       > It has no relation to the SRC_URI, probably a run of the mill bug in
>       > the processing code. I'd suggest taking it up with Wind River
>       > support.
>       >
>       > Alternatively, if you have this somewhere that I clone and launch a
>       > test build, I can help you out .. but I won't be able to easily
>       > reproduce that situation from scratch.
>
>         ok, i found what appears to be a cheap workaround for this, and i'm
>       curious if this makes any sense.  recall original kernel recipe
>       directory structure:
>
>         linux-windriver/
>           uio.*
>           ssd.*
>           mxeiii/
>             mm.*
>
>       when SRC_URI mentioned only that first-level stuff (uio, ssd), then
>       the configure step worked fine. but as soon as i added the mm.scc file
>       to SRC_URI, it just seems that any descent into a lower-level
>       directory based on OVERRIDES totally bones the search process. so, i
>       wondered, how can i work around this?
>
>         oh, wait, no problem. see, all target boards are powerpc, so
>       "powerpc" is one of the possible OVERRIDES. obviously, there is no
>       *actual* value in using an OVERRIDE for which *every* *single* *board*
>       is compatible ... oh, wait, there is.
>
>         so i restructured:
>
>         linux-windriver/
>           mxeiii/
>             mm.*
>           powerpc/
>             uio.*
>             ssd.*
>
>       it looks idiotic to take the uio.* and ssd.* content, which should be
>       generic, and deliberately put it in a subdirectory, unless that
>       subdirectory represents an OVERRIDE which matches every board and, ta
>       da, solves the problem.
>
>         i need a drink.
>
>
> Following up to the list. I was able to take a reproducer for this
> and indeed find some *really* old code that didn't handle a trailing
> / properly. The end result was the inability to find the
> configuration fragments that were not in subdirectories.

  just to be clear, there was no problem finding config fragments that
were not in subdirectories until i somehow triggered the bug by
*adding* an item that *was* in a subdirectory, and that's when things
went to hell.

  so the "bug" apparently never manifested itself until i triggered it
by doing something else. does that sound about right?

rday