Re: [yocto-patches] [auh][PATCH 2/3] modules/steps.py: refactor compile() to use parallel per-machine builds

On Mon, 27 Apr 2026 at 04:09, ChenQi <[email protected]> wrote:

> With this parallel build added, Yocto can configure oe-core's upgrade to
> use machines that oe-core uses as the acceptance criteria. This means a
> successful auh upgrade will very like to be merged without any change.
> If there is some failure, e.g., qemuarm64_musl, the
> developers/maintainers can see it directly without doing more local builds.

For the purpose of updating oe-core, I feel a bit different about
benefits of adding more machines actually. I think it's unlikely that
adding more entries to the two existing ones (qemux86_64 and
qemuarm_musl) will help uncover more issues - if 32 bit and musl
variants are already covered between these two, then it's unlikely
there will a particular 32 bit x86 issue, or 64 bit arm issue, or a
risc-v issue, e.g. something that those additional machines would
catch.

It's far more likely that an update builds fine by itself, but breaks
something not covered by AUH recipe builds, e.g. a dependent recipe,
ptests, oe-selftest, or runtime behavior. Such things are unrealistic
to test for each update, and so they're done after the fact, in
a-full.

I agree that speeding up AUH would be beneficial, but that is better
done in the outermoost loop, which takes recipe groups and updates
them one by one. Parallelizing that is more complicated, as each
update operation would need its own copy of oe-core repo in addition
to its own build directory, but it would really run everything in
parallel, including devtool upgrade (which can be very sluggish on
large source trees or large commit histories), buildhistory, and test
builds. And of course, lack of AUH tests hinders such large refactor
efforts as well.

Alex