On Wed, 20 Apr 2016, Martin Jansa wrote: > 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/
yes, and they all look fine, but here's the latest development which should clarify things. here's the structure of the generic linux-windriver/ directory, under which the search should look for anything which hasn't matched anything more specific in terms of a kernel version: linux-windriver/ ├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch ├ mxeiii ... mxe board specific stuff but *no* uio-related stuff ├── uio.cfg └── uio.scc so what we have is the UIO stuff *immediately* under linux-windriver/, which is where it should be found (there is no other UIO content anywhere else in the recipe directory). after doing the configure, here's the content of bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log: [INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg note carefully how that second line shows clearly where the uio.cfg file is being found(?): linux-windriver/uio.cfg and that's for the board that works. however, for the second board (the mxeiii for which there *is* a subdirectory that should be examined), here's the equivalent config.log file: [INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/uio.cfg [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist note the difference in the second line in the two cases -- the subdirectory name "linux-windriver" has disappeared, hence the second case fails miserably in locating the config fragment file uio.cfg. it's as if (and i'm just making this up now) the fact that a more specific "mxeiii" subdirectory under linux-windriver/ somehow screws up the search process. (if i redundantly duplicate those UIO files in the mxeiii/ subdirectory, then everything works fine, but that should *not* be necessary.) is there something about the SRC_URI search order that i'm unaware of? should each SRC_URI item start a brand new, independent search? i've been fighting with this for a while, and it simply makes no sense to me. 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