Re: [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2023-10-31 at 13:08 +0100, Alexander Kanavin wrote:
> On Mon, 30 Oct 2023 at 16:02, Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> > So here's what could be done:
> > 
> > - esdk tools become symlinks in poky/scripts/esdk-tools/. esdk
> > environment script puts that in PATH, rather than some custom
> > esdk-specific location (the code to generate that can then be
> > dropped).
> 
> This is now implemented (needs to be tested on AB).
> 
> > - esdk tweaks to local.conf move into a dedicated include file, which
> > can be static and under version control, except for perhaps
> > METADATA_REVISION:poky = "4a1e0b9625729e422fcf24e632ee2a3c79f986d5" -
> > I need to check why is it there and how that is used.
> 
> It's actually more complicated. The code to generate esdk-specific
> local.conf with all the tweaks has too much dynamic stuff in it which
> is subject to what various variables are set to. So I'm thinking of
> extracting that to a dedicated function, then attaching a bitbake task
> to that function.
> 
> Then we can pull all of it together into 'devtool esdk <image>'
> command (or similar), which would enter the esdk environment directly
> via:
> - running 'bitbake <image> meta-ide-support'
> - running the above mentioned bitbake local.conf task to generate the
> esdk-specific local.conf
> - sourcing the environment script produced by meta-ide-support
> - rewriting PATH to provide only the curated esdk tools and not
> everything plus bitbake.
> - writing a custom devtool.conf similar to that of standalone esdk so
> that devtool can find bitbake and bitbake can use the esdk-specific
> local.conf
> 
> And it would be tested in the same way standalone esdks are.
> 
> Thoughts? Anything missing from the above list?

That sounds like a good way to handle this to me!

Cheers,

Richard