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.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
