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.ja...@gmail.com
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
