From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: "chris.laplante@agilent.com" <chris.laplante@agilent.com>,
openembedded-architecture
<openembedded-architecture@lists.openembedded.org>,
Yocto-mailing-list <yocto@lists.yoctoproject.org>,
",openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
Julien STEPHAN <jstephan@baylibre.com>
Subject: Re: [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
Date: Thu, 28 Sep 2023 17:49:50 +0100 [thread overview]
Message-ID: <7564ae2b6c036b10a35e8c9927c0ab2cf533f35c.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANNYZj-YBTN_yje-fyzp12YDF9XMaZSuMvLh6qA1H+9GEYEmfA@mail.gmail.com>
On Thu, 2023-09-28 at 18:43 +0200, Alexander Kanavin wrote:
> On Fri, 22 Sept 2023 at 12:42, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > Things which used to be problematic:
> >
> > a) changes involving changes to gcc-source since it uses a shared
> > sources stamps which confused the tools (at least used to). That may
> > have been before gcc-source became a recipe?
> > b) changes to a very common component (e.g. autoconf-native's
> > do_configure) which make it hard to understand where the root cause of
> > the changes came from
> > c) changes which affect many recipes at once, e.g. the do_configure
> > function in base.bbclass
> >
> > It might be helpful to write test cases for the scenario you showed as
> > working above and some of the ones I mention above, then we can
> > document they work and have an easier way to add tests for issues
> > if/as/when we identify the problematic scenarios in future.
>
> I've now written down the tests for these three scenarios and got them
> to pass (in oe-selftest too \0/):
> https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all
> (check the commit message too)
>
> I am going to look closer at bitbake-whatchanged, what it aims to do
> and why it doesn't work. I have a hunch it can produce useful high
> level reports, and so shouldn't be simply thrown away. 'bitbake -S
> printdiff' is too techy and verbose for some use cases. Maybe we can
> fold that functionality into 'bitbake -S whatchanged'.
I've wondered if we should split bitbake -S printdiff into a separate
utility? It exists from a time before we had bitbake command APIs.
I'm curious to see what you find with analysis of bitbake-whatchanged.
I'm also somewhat surprised the scenarios you're testing all work!
I'm guess one of the commits I pointed to must have fixed them (the
removal of paths from the sig files)?
Cheers,
Richard
next prev parent reply other threads:[~2023-09-28 16:49 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 14:44 Yocto Project Status 12 September 2023 (WW37) Stephen K Jolley
2023-09-14 11:52 ` Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused? Alexander Kanavin
2023-09-14 12:56 ` Richard Purdie
2023-09-14 18:51 ` Alexander Kanavin
2023-09-14 19:54 ` Richard Purdie
2023-09-15 8:28 ` Alexander Kanavin
2023-09-20 14:25 ` Julien Stephan
2023-09-20 14:31 ` Alexander Kanavin
2023-09-20 18:04 ` Julien Stephan
2023-09-21 11:11 ` Alexander Kanavin
2023-09-21 14:39 ` [Openembedded-architecture] " chris.laplante
2023-09-21 14:39 ` Chris Laplante
2023-09-22 9:17 ` Alexander Kanavin
2023-09-22 10:42 ` Richard Purdie
2023-09-28 16:43 ` Alexander Kanavin
2023-09-28 16:49 ` Richard Purdie [this message]
2023-09-28 17:07 ` Alexander Kanavin
2023-09-29 12:06 ` Alexander Kanavin
2023-09-29 12:27 ` Richard Purdie
2023-09-29 13:09 ` Alexander Kanavin
2023-11-01 14:18 ` [OE-core] " adrian.freihofer
2023-11-01 15:19 ` Alexander Kanavin
2023-11-01 17:20 ` [Openembedded-architecture] " adrian.freihofer
2023-11-04 10:29 ` adrian.freihofer
2023-11-04 11:09 ` Richard Purdie
2023-11-05 19:43 ` adrian.freihofer
2023-11-06 11:48 ` Alexander Kanavin
2023-11-06 19:42 ` [Openembedded-architecture] " Mark Hatle
2023-10-30 13:50 ` Alexander Kanavin
2023-10-30 14:07 ` Richard Purdie
2023-10-30 15:02 ` Alexander Kanavin
[not found] ` <1792EACC19CD8046.7262@lists.openembedded.org>
2023-10-31 12:08 ` [OE-core] " Alexander Kanavin
2023-10-31 12:28 ` Richard Purdie
2023-10-31 13:53 ` Alexander Kanavin
2023-11-01 15:45 ` [yocto] " adrian.freihofer
2023-11-01 17:28 ` Alexander Kanavin
2023-11-02 8:32 ` adrian.freihofer
2023-11-02 9:02 ` Alexander Kanavin
[not found] ` <1793C2E61248AF31.11290@lists.yoctoproject.org>
2023-11-02 11:51 ` Alexander Kanavin
2024-01-22 10:47 ` Alexander Kanavin
[not found] ` <17ACA59E7A7FD97B.16230@lists.openembedded.org>
2024-02-05 20:35 ` [OE-core] " Alexander Kanavin
2024-02-05 21:11 ` Richard Purdie
2024-02-08 13:35 ` Alexander Kanavin
2024-02-08 13:42 ` Richard Purdie
2024-02-13 13:25 ` Alexander Kanavin
2024-02-13 13:44 ` Richard Purdie
2024-02-13 14:05 ` Alexander Kanavin
2024-02-13 14:28 ` Joshua Watt
2024-02-14 6:31 ` Alexander Kanavin
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=7564ae2b6c036b10a35e8c9927c0ab2cf533f35c.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alex.kanavin@gmail.com \
--cc=chris.laplante@agilent.com \
--cc=jstephan@baylibre.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=yocto@lists.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.