From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Paul Barker <pbarker@konsulko.com>
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, 08 Dec 2020 12:19:55 +0000 [thread overview]
Message-ID: <0f923cdcf0ff0ea8e4ed5bb8fdbe568f3a904446.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAM9ZRVuTxAwqRAntHaf5UGg2iiAPW=KBC7v0hCM02J0a8WgPyg@mail.gmail.com>
On Tue, 2020-12-08 at 08:48 +0000, Paul Barker wrote:
> 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.
I'm wondering if we should just set:
sys.dont_write_bytecode=True
since the number of places we'd get significant speed from this is
limited. We probably only need to do this in any pseudo using code
paths?
Cheers,
Richard
next prev parent reply other threads:[~2020-12-08 12:19 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
2020-12-08 10:17 ` Richard Purdie
2020-12-08 12:19 ` Richard Purdie [this message]
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=0f923cdcf0ff0ea8e4ed5bb8fdbe568f3a904446.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=pbarker@konsulko.com \
--cc=peter.kjellerstedt@axis.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox