On Mon, 2023-11-06 at 16:00 +0100, Rasmus Villemoes wrote:
> Somewhat related, but maybe not really:
>
> When I set PACKAGECONFIG for perf in a perf.bbappend file, without
> python being in there, the build breaks:
>
> > Makefile.config:277: ***
> .../tmp/work/qemuarm64-poky-linux/perf/1.0/recipe-sysroot-native/usr/bin/python3-native/python3-config
> not found. Stop.
> > make[1]: *** [Makefile.perf:242: sub-make] Error 2
>
> If I instead set the same PACKAGECONFIG value, but by doing
>
> PACKAGECONFIG:pn-perf = "tui libunwind libtraceevent"
>
> in some global configuration file, it works as expected.
>
> ====
>
> I think the difference is due to the
>
> inherit ${@bb.utils.contains('PACKAGECONFIG', 'python',
> 'python3targetconfig', '', d)}
>
> line in the perf recipe. At the time where this line is evaluated, if
> PACKAGECONFIG is set via a .bbappend, this ends up evaluated using the
> ??= value which does include python, and hence we end up inheriting
> python3targetconfig, which in turn inherits python3native, which does
>
> export PYTHON
>
> And since PYTHON is now exported, perf's logic ends up in this fragment
> in tools/perf/Makefile.config:
>
> # If PYTHON is defined but PYTHON_CONFIG isn't, then take
> $(PYTHON)-config as if it was the user
> # supplied value for PYTHON_CONFIG. Because it's "user supplied", error
> out if it doesn't exist.
> ifdef PYTHON
> ifndef PYTHON_CONFIG
> PYTHON_CONFIG_AUTO := $(call get-executable,$(PYTHON)-config)
> PYTHON_CONFIG := $(if $(PYTHON_CONFIG_AUTO),$(PYTHON_CONFIG_AUTO),\
> $(call $(error $(PYTHON)-config not found)))
> endif
> endif
>
> which breaks because the value of PACKAGECONFIG that ended up
> determining buildtime dependencies did not pull in that python3-config.
>
> ====
>
> This difference is, to put it mildly, quite confusing and surprising
> (and took quite some time to track down). I don't know if there's
> anything to do about it. Is setting PACKAGECONFIG via :pn-foo overrides
> the only supported method, or is this just a quirk of the perf recipe
> that one has to live with?
That is a pretty horrible interaction of things. As you say, that
inherit is effectively an immediate expansion of the data and wouldn't
"see" changes in any bbappend.
Could you file a bug please?
I'm wondering if we should have some other form of inherit which
applies at the end of parsing which would avoid that issue. Sometimes
order is important, sometimes it is less important with the inherits.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190225):
https://lists.openembedded.org/g/openembedded-core/message/190225
Mute This Topic: https://lists.openembedded.org/mt/102420698/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
