> On 15 May 2023, at 15:49, Petr Kubizňák - 2N <kubiz...@2n.com> wrote: > The key question is whether the problematic packages have intrinsic > dependency on g-i-native, which can (and should) be fixed by adding the > package in DEPENDS directly, or g-i-native is always needed as Ross says, > which would imply g-i-native should not be conditioned by GI_DATA_ENABLED in > the class. > > I'm not an expert on g-i so I didn't have strong arguments but feel free to > convince Alex that g-i-native should be always in DEPENDS.
If we grab a package from git that has a empty m4/ and it has optional support for G-I then it needs a dependency on gobject-introspection-native so that it has introspection.m4 available. We already inherit gobject-introspection.bbclass, so the dependency can be there. I don’t see why g-i.bbclass would only pull in fundamental build dependencies when it’s enabled. Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181265): https://lists.openembedded.org/g/openembedded-core/message/181265 Mute This Topic: https://lists.openembedded.org/mt/98032505/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
