I don't have a strong opinion here. Petr wanted to trim dependencies down to bare minimum, but if we need to strike a more reasonable balance, that's fine.
Alex On Mon, 15 May 2023 at 18:43, Ross Burton <ross.bur...@arm.com> wrote: > > > > > 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 (#181401): https://lists.openembedded.org/g/openembedded-core/message/181401 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] -=-=-=-=-=-=-=-=-=-=-=-
