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

[Martin Jansa]

On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> 
>   (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?

Did you check FILESPATH variable to see order of directories how they
are searched?

e.g.:
$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160420/f8d55abf/attachment.pgp>