All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?
Date: Wed, 20 Apr 2016 20:04:21 +0200	[thread overview]
Message-ID: <20160420180421.GD2561@jama> (raw)
In-Reply-To: <alpine.LFD.2.20.1604201229260.24374@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]

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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2016-04-20 18:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 16:42 is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files? Robert P. J. Day
2016-04-20 18:04 ` Martin Jansa [this message]
2016-04-20 18:31   ` Robert P. J. Day
2016-04-20 18:58     ` Bruce Ashfield
2016-04-20 19:05       ` Robert P. J. Day
2016-04-20 21:19       ` Robert P. J. Day
2016-04-20 22:37       ` Robert P. J. Day
2016-04-21  2:46         ` Bruce Ashfield
2016-04-21  8:59           ` Robert P. J. Day
2016-04-21 13:32             ` Bruce Ashfield
2016-04-20 19:00   ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160420180421.GD2561@jama \
    --to=martin.jansa@gmail.com \
    --cc=rpjday@crashcourse.ca \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.