All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Barker" <pbarker@konsulko.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
	 openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCHv3 2/5] bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Date: Tue, 8 Dec 2020 08:48:49 +0000	[thread overview]
Message-ID: <CAM9ZRVuTxAwqRAntHaf5UGg2iiAPW=KBC7v0hCM02J0a8WgPyg@mail.gmail.com> (raw)
In-Reply-To: <88d9a9dea0420aa5944c0acba44f14f6eb24d771.camel@linuxfoundation.org>

On Mon, 7 Dec 2020 at 12:46, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2020-12-07 at 12:04 +0000, Paul Barker wrote:
> > On Mon, 7 Dec 2020 at 10:29, Paul Barker <pbarker@konsulko.com>
> > wrote:
> > To follow up some more: The entries in PSEUDO_IGNORE_PATHS are
> > treated
> > as string prefixes within pseudo. So if
> > "/home/pbarker/Projects/Yocto/meta-linux-mainline" is added to the
> > ignore list it will exclude not just
> > "/home/pbarker/Projects/Yocto/meta-linux-mainline/build" but also
> > ""/home/pbarker/Projects/Yocto/meta-linux-mainline-build".
> >
> > I wonder if some more of those entries should have trailing slashes.
>
> In most (all?) cases it was very deliberate FWIW...

That does make sense. Ignoring "${COREBASE}/meta" will also ignore
most layers unpacked or cloned within the poky directory as their
names start with "meta". However that does miss layers if you use a
different directory structure which is what Peter's patch addresses
(though I'm still not sure if there's an actual build failure with
some layers which it is intended to fix or if it's just to make things
consistent).

The issue comes when you clone a layer as the top-level of your
working tree and build within that. That's how I work with
meta-sancloud & meta-linux-mainline. It's also what happens if you
build using the kas config in meta-raspberrypi. So it's not uncommon.

Investigating why the layer directories are being ignored I found this
commit added the ignore of "${COREBASE}/meta":

    commit e0cb6dd689a362d8433caa14cc5a9fdd5eb44923
    Author: Richard Purdie <richard.purdie@linuxfoundation.org>
    Date:   Wed Oct 7 23:08:45 2020 +0100

       bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta

        Unfortunately, .pyc files can be generated in meta/lib/oe
which corrupt the pseudo
        database so we need to extend the ignore list to cover this as well.

        Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Could we instead ignore "${LAYERDIR}/lib" for each layer?

An alternative would be to detect the case where TOPDIR or TMPDIR is
beneath an entry in BBLAYERS and handle that as a special case.

Thanks,

-- 
Paul Barker
Konsulko Group

  reply	other threads:[~2020-12-08  8:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 18:11 [PATCHv3 0/5] Support symbolic links in paths in PSEUDO_IGNORE_PATHS Peter Kjellerstedt
2020-12-01 18:11 ` [PATCHv3 1/5] pseudo: Simplify pseudo_client_ignore_path_chroot() Peter Kjellerstedt
2020-12-01 18:11 ` [PATCHv3 2/5] bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS Peter Kjellerstedt
2020-12-07 10:29   ` [OE-core] " Paul Barker
2020-12-07 12:04     ` Paul Barker
2020-12-07 12:46       ` Richard Purdie
2020-12-08  8:48         ` Paul Barker [this message]
2020-12-08 10:17           ` Richard Purdie
2020-12-08 12:19           ` Richard Purdie
2020-12-01 18:11 ` [PATCHv3 3/5] lib/oe/path: Add canonicalize() Peter Kjellerstedt
2020-12-01 18:11 ` [PATCHv3 4/5] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS Peter Kjellerstedt
2020-12-01 18:11 ` [PATCHv3 5/5] wic: Pass canonicalized " Peter Kjellerstedt

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='CAM9ZRVuTxAwqRAntHaf5UGg2iiAPW=KBC7v0hCM02J0a8WgPyg@mail.gmail.com' \
    --to=pbarker@konsulko.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    --cc=richard.purdie@linuxfoundation.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.