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