[meta-oe] nodejs: ignore QEMU_OPTIONS for native signature generation

NodeJS recipe uses qemu to run some target binaries during compilation
in qemu, in case the build machine's and the target machine's CPU
bit-width are different. The task that generates some helper scripts
(do_create_v8_qemu_wrapper) is executed before do_compile.

In case the target machine changes, that also changes the value of
QEMU_OPTIONS variable, since that is always derived from the target
machine's properties, even when the current recipe is class-native.

This also means that in case the target machine changes, that invalidates
the do_create_v8_qemu_wrapper's sstate cache (along with the very costly
do_compile), for both target and native builds.

However for native builds qemu isn't used at all, since the target and build
CPU are the same, their bit-width matches too.

To avoid unnecessarily invalidating the sstate cache of nodejs-native
when the target machine changes, add QEMU_OPTIONS to BB_HASHCONFIG_IGNORE_VARS
in order to exclude it from the signature generation.

Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
---
 meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

This looks like a better fix possible. Why is qemu a dependency for
native variant to begin with, if it's not used? Shouldn't that
dependency be eliminated?

Otherwise, this is prone to regressions if some other qemu-related
variable starts invalidating sstate.

Alex


On Sat, 21 Jun 2025 at 21:40, Gyorgy Sarvari via
lists.openembedded.org <skandigraun=gmail.com@lists.openembedded.org>
wrote:
>
> NodeJS recipe uses qemu to run some target binaries during compilation
> in qemu, in case the build machine's and the target machine's CPU
> bit-width are different. The task that generates some helper scripts
> (do_create_v8_qemu_wrapper) is executed before do_compile.
>
> In case the target machine changes, that also changes the value of
> QEMU_OPTIONS variable, since that is always derived from the target
> machine's properties, even when the current recipe is class-native.
>
> This also means that in case the target machine changes, that invalidates
> the do_create_v8_qemu_wrapper's sstate cache (along with the very costly
> do_compile), for both target and native builds.
>
> However for native builds qemu isn't used at all, since the target and build
> CPU are the same, their bit-width matches too.
>
> To avoid unnecessarily invalidating the sstate cache of nodejs-native
> when the target machine changes, add QEMU_OPTIONS to BB_HASHCONFIG_IGNORE_VARS
> in order to exclude it from the signature generation.
>
> Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
> ---
>  meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb b/meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb
> index 4bc829f140..bf2bae27f1 100644
> --- a/meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb
> +++ b/meta-oe/recipes-devtools/nodejs/nodejs_22.16.0.bb
> @@ -47,6 +47,10 @@ CVE_PRODUCT += "node.js"
>  # v8 errors out if you have set CCACHE
>  CCACHE = ""
>
> +# Changing qemu options can incorrectly invalidate sstate, even though it is not used.
> +# Exclude it from signature generation.
> +BB_HASHCONFIG_IGNORE_VARS:append:class-native = " QEMU_OPTIONS "
> +
>  def map_nodejs_arch(a, d):
>      import re
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#118011): https://lists.openembedded.org/g/openembedded-devel/message/118011
> Mute This Topic: https://lists.openembedded.org/mt/113762550/1686489
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On 6/23/25 07:35, Alexander Kanavin wrote:
> This looks like a better fix possible. Why is qemu a dependency for
> native variant to begin with, if it's not used? Shouldn't that
> dependency be eliminated?
>
> Otherwise, this is prone to regressions if some other qemu-related
> variable starts invalidating sstate.

Unfortunately you are right - that was the reason for withdrawing this
patch, I started to run into new variables. Since this patch was a
failure, currently I'm testing a patch with conditional qemu class
inheritance, which should only pull it in when needed. So far it hasn't
blown up - if it stays like this, will give this submission another go
later today.

> Alex
>