If you have a bit of time, I'd suggest that you check the failures one by one. Some of it, like missing glib-* executables seems like a trivial missing dependency which was previously pulled in indirectly. Others, like python3-pygobject probably have a hard dependency on g-i. I'm slowly progressing with the patch but always end up at the principal issue of hard dependency on g-i being enabled.
For example, graphene recipe does not reflect on "gobject-introspection-data" being/not being in distro features, claiming gtk4 requires build with introspection. Graphene can be patched to be buildable under both circumstances but gtk4 then (unsurprisingly) fails in do_configure step due to missing graphene-gobject-1.0 if g-i is disabled. I don't think gtk4 can be patched to build with g-i disabled, do you? If you agree with me, how can we proceed with the fact that some packages (namely gtk4) basically cannot be built without the feature, while still allowing to disable that feature? Is it really necessary to have everything buildable with g-i disabled? Apparently, it's not buildable now. Petr ________________________________ From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> on behalf of Alexander Kanavin <alex.kana...@gmail.com> Sent: Monday, January 9, 2023 10:20 AM To: Petr Kubizňák - 2N <kubiz...@2n.com> Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED On Fri, 6 Jan 2023 at 19:52, Petr Kubizňák <kubiz...@2n.com> wrote: > When the patch is _applied_ and g-i is _disabled_, graphene does build, but > some other packages don't: ... > This shows that these packages depend on gobject-introspection and/or its > dependencies no matter whether introspection is enabled or disabled. I don't > know these packages so I don't think I'm able to patch them properly. On the > other hand, I still believe it is incorrect to pull in the unnecessary > dependencies when g-i is disabled. What do you think? > This is what I was worried about. It uncovers a whole list of failures, and creates a new maintenance burden going forward, as fixing them will be an ongoing activity in the absence of an unconditional g-i dependecy.. If you have a bit of time, I'd suggest that you check the failures one by one. Some of it, like missing glib-* executables seems like a trivial missing dependency which was previously pulled in indirectly. Others, like python3-pygobject probably have a hard dependency on g-i. It does require navigating your way around unfamiliar source code, which is a useful skill in yocto regardless. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176030): https://lists.openembedded.org/g/openembedded-core/message/176030 Mute This Topic: https://lists.openembedded.org/mt/96048399/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
