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

[Bruce Ashfield]

On Thu, Apr 21, 2016 at 4:59 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

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

Correct. The subdirs were getting a trailing / and hence when the fragments
were
all gathered up (in case the original location is remote), they were being
dumped
into .kernel-meta/cfg/<the absolute path to the fragment>/foo.cfg.

Later on the configuration was looking for them in just <subdir>/foo.cfg ..
and
couldn't find them.

Bloody trailing slashes!

Bruce


>
> rday




-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160421/7bc04a9a/attachment.html>