Re: [OE-core] [PATCH v2 4/5] llvm-project-source.inc: add vardeps to do_preconfigure

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

On Mon, 2026-06-29 at 10:09 +0200, Joao Marcos Costa wrote:
> On 6/28/26 12:25, Richard Purdie via lists.openembedded.org wrote:
> > On Tue, 2026-06-23 at 14:08 +0200, Joao Marcos Costa via lists.openembedded.org wrote:
> > > The task's signature should change if CLANG_EXTRA_OE_DISTRO and/or
> > > CLANG_EXTRA_OE_VENDORS, considering the couple of for loops in
> > > do_preconfigure iterate over their values.
> > > 
> > > By adding them to 'vardeps', bitbake will correctly detect if
> > > do_preconfigure needs to be executed.
> > > 
> > > Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
> > > ---
> > >   meta/recipes-devtools/clang/llvm-project-source.inc | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/recipes-devtools/clang/llvm-project-source.inc b/meta/recipes-devtools/clang/llvm-project-source.inc
> > > index 85b5ef06dc..84d4bae0ab 100644
> > > --- a/meta/recipes-devtools/clang/llvm-project-source.inc
> > > +++ b/meta/recipes-devtools/clang/llvm-project-source.inc
> > > @@ -90,4 +90,5 @@ python do_preconfigure() {
> > >   
> > >   do_patch[vardepsexclude] += "MULTILIBS MULTILIB_VARIANTS"
> > >   addtask do_preconfigure after do_patch
> > > +do_preconfigure[vardeps] += "CLANG_EXTRA_OE_DISTRO CLANG_EXTRA_OE_VENDORS"
> > >   do_create_spdx[depends] += "${PN}:do_preconfigure"
> > 
> > We require that tasks can run in isolation and that can happen for many
> > different reasons. Your fix does improve things a bit but it doesn't
> > fix the underlying problem.
> > 
> > Ideally we'd change the search/replace expressions so that they always
> > change/update the required entries. That does sometimes need a bit more
> > thought about how the expressions work and it means you can't use
> > replacement tokens (unless as a comment on the line above?).
> > 
> > Another less optimal way to improve things is to change do_preconfigure
> > into a postfunc for do_unpack, but it wouldn't be able to change things
> > altered by do_patch. You can't make it a do_patch postfunc as it could
> > still have the current issues with the changes not being updated.
> > 
> > Cheers,
> > 
> > Richard
> 
> I see your point. I'd be more eager to have a reproducible 
> search/replace strategy than using postfuncs, but this would require 
> some more time, and I will soon be OOO for a few days.
> 
> What is the perspective for this series? Does it heavily depend on this 
> last part? I would prefer not to delay this fix any longer, and I could 
> send another series later to add some testing (to avoid regressions in 
> the future), and a more solid search/replace in do_preconfigure.

I've merged the first 3 patches, those makes sense on their own. I'm a
bit more reluctant for the last two as I really would like to fix the
issue correctly...

Cheers,

Richard