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). 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). Alex -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
