On 06/11/2023 15.49, Bruce Ashfield wrote: > On Mon, Nov 6, 2023 at 9:22 AM Rasmus Villemoes > <rasmus.villem...@prevas.dk> wrote: >> >> From: Rasmus Villemoes <rasmus.villem...@prevas.dk> >> >> Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3, >> without "python" in PACKAGECONFIG, results in >> >> | Makefile.config:892: *** ERROR: No python interpreter needed for jevents >> generation. Install python or build with NO_JEVENTS=1.. Stop. >> >> Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk> >> --- >> meta/recipes-kernel/perf/perf.bb | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/meta/recipes-kernel/perf/perf.bb >> b/meta/recipes-kernel/perf/perf.bb >> index a392166e73..37b53ee7df 100644 >> --- a/meta/recipes-kernel/perf/perf.bb >> +++ b/meta/recipes-kernel/perf/perf.bb >> @@ -28,6 +28,7 @@ PACKAGECONFIG[audit] = ",NO_LIBAUDIT=1,audit" >> PACKAGECONFIG[manpages] = ",,xmlto-native asciidoc-native" >> PACKAGECONFIG[cap] = ",,libcap" >> PACKAGECONFIG[libtraceevent] = ",NO_LIBTRACEEVENT=1,libtraceevent" >> +PACKAGECONFIG[jevents] = ",NO_JEVENTS=1,python3-native" > > Since we already have a python packageconfig and it takes care of > the dependencies that we need, we shouldn't be repeating the python3-native > in this one. We'll end up having to maintain that dependency in > two locations. > > i.e. we don't have python3-native as a dependency of our main python > packageconfig .. is that an error (the python packageconfig) or should > this be depending on python3 python3-setuptools-native, just like the > python one ?
The two are as I understand it entirely unrelated. The existing python knob controls whether some stuff that requires python at runtime is built/installed (and that build may of course itself require some native python, in this case in the guise of setuptools-native). The jevents stuff is purely about generating some tables [as a .c file] at build time, and that requires native python, but does not impose a dependency on python on target. > Since there's no way to make packageconfig 'a' depend on > packageconfig 'b' that I know of (RP will correct me if I'm missing > or forgetting something here), we could always add a test on the > final PACKAGECONFIG and error/warn if jevents was enabled and > python wasn't. I don't think it's correct to force jevents pc to include python pc, as the latter will make the perf binary pull in the whole python interpreter etc. If feature A depends on foo-native and foo and bar, and feature B requires foo-native, I don't see why one should be forced to enable feature A in order to get B. [Conversely, even if the dependencies of feature A today happen to be a superset of those of feature B, I don't think selecting feature A should automatically imply feature B.] > It is always a bit annoying that perf turns these on, and we have > to explicitly opt-out .. but that is out of our control :) Indeed. Rasmus
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#190227): https://lists.openembedded.org/g/openembedded-core/message/190227 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] -=-=-=-=-=-=-=-=-=-=-=-
