[yocto] is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?
Bruce Ashfield
bruce.ashfield at gmail.com
Wed Apr 20 11:58:28 PDT 2016
On Wed, Apr 20, 2016 at 2:31 PM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:
> 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.
>
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.
Cheers,
Bruce
>
> 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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160420/3d7a9ace/attachment.html>
More information about the yocto
mailing list