On Mon, Apr 1, 2019 at 6:36 PM Alexander Kanavin <alex.kana...@gmail.com> wrote: > > On Mon, 1 Apr 2019 at 18:21, Andreas Müller <schnitzelt...@gmail.com> wrote: > > > > I honestly don't remember why the whitelisting was considered a good > > > idea, but I think it would be better to drop it altogether? That way > > > there will be no silent regressions (when upstream decides to rename > > > the option, for example, which does happen). > > > > > Whitelisting would make sense for for projects where gir is mandatory > > and cannot be disabled by configuration - are there any? > > For autotools, basically no, as they all use the same m4 macro file > which allows disabling. > > For meson or other build systems the answer is also no, because in > this case we would have to patch the upstream code to either make gir > generation optional (and then 'inherit gobject-introspection'), or > disable it altogether (and then don't inherit g-i at all). The reason > is that introspection data generation is done through running a target > binary, which requires a functional qemu usermode, and for some target > MACHINEs qemu won't work (e.g. mips-n32, some flavours of powerpc etc > - g-i class determines that and does the right thing to disable > introspection automatically). What about musl? Am not sure that my information is still valid: Broken qemu or not? > Here's an example of such patching: > > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/libmodulemd/libmodulemd/0002-modulemd-v1-meson.build-do-not-generate-gir-or-gtkdo.patch?id=f06d14b2963e9d5145041057c3ad0e48654f1501 > > (newer versions of libmodulemd made g-i optional, and so the current > oe-core recipe and its patches reflects that). > I will prepare follow ups:
* remove whitelisting (see what we get) * adapt recipes in oe-core Seems all this is too late for warrier (that was my target - am again too late - maybe next time :). So I think I'll continue with gnome-de for warrier first (with oe-core as is). Maybe I get patches landed before doors are shut for meta-gnome... Will come back then Andreas -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core