gobject introspection to oe-core

gobject introspection to oe-core

[Alexander Kanavin]

Hello,

I'm looking into the possibility of adding gobject introspection support 
directly to oe-core for Yocto 2.1 release (Spring 2016). This work would 
of course be based on meta-gir, but with the mandatory goal of producing 
patches of sufficient quality that can be sent upstream.

I know the upstream tarball is a mess that mashes together several 
different things and was never designed for cross-compiling; and 
meta-gir is also difficult to understand: autotools-based build files 
are patched using undocumented patchfiles, then again patched from the 
recipe using sed, with no comments anywhere - all that needs to be sorted.

What's your take on this? Is it realistic? Would you be able to help out?

Regards,
Alexander

Re: gobject introspection to oe-core

[Changhyeok Bae]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

Hi

Thanks for your suggestion. I also would like to support gir in oe-core.
However, I need to cleanup the recipes now as you said. I will think about
it because of my schedule :(.

I'll contact you when I'm ready for it.
Thanks

2015년 10월 6일 화요일, Alexander Kanavin<alexander.kanavin@linux.intel.com>님이
작성한 메시지:

> Hello,
>
> I'm looking into the possibility of adding gobject introspection support
> directly to oe-core for Yocto 2.1 release (Spring 2016). This work would of
> course be based on meta-gir, but with the mandatory goal of producing
> patches of sufficient quality that can be sent upstream.
>
> I know the upstream tarball is a mess that mashes together several
> different things and was never designed for cross-compiling; and meta-gir
> is also difficult to understand: autotools-based build files are patched
> using undocumented patchfiles, then again patched from the recipe using
> sed, with no comments anywhere - all that needs to be sorted.
>
> What's your take on this? Is it realistic? Would you be able to help out?
>
> Regards,
> Alexander
>

[-- Attachment #2: Type: text/html, Size: 1393 bytes --]

Re: gobject introspection to oe-core

[Andreas Müller]

On Tue, Oct 6, 2015 at 2:27 PM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> Hello,
>
> I'm looking into the possibility of adding gobject introspection support
> directly to oe-core for Yocto 2.1 release (Spring 2016). This work would of
> course be based on meta-gir, but with the mandatory goal of producing
> patches of sufficient quality that can be sent upstream.
>
> I know the upstream tarball is a mess that mashes together several different
> things and was never designed for cross-compiling; and meta-gir is also
> difficult to understand: autotools-based build files are patched using
> undocumented patchfiles, then again patched from the recipe using sed, with
> no comments anywhere - all that needs to be sorted.
>
> What's your take on this? Is it realistic? Would you be able to help out?
>
> Regards,
> Alexander
> --
I appreciate this very much - missing gir was a blocker many times for
me. Especially if you'd manage to turn gir to more cross friendly
state.
Regarding support: Depends on my current challenges but running tests
and reviews should be possible for me.

Andreas

gobject introspection to oe-core

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Hi,
I have done some testing of Alex's branch "akanavin/gobject-introspection-experimental", originally http://patchwork.openembedded.org/patch/107089/ 
I have built this successfully for x86 and x64 targets on an x64 build machine:
meta              meta-yocto        meta-yocto-bsp    = "akanavin/gobject-introspection-experimental:04c7746ce90abc14604dec3328b9472c53cccf98"meta-networking   meta-oe           meta-python       = "master:47f7d287a09329734629cb9d194ef4e077117d79"meta-haswell-wc   meta-intel        = "master:6e91701dcf68f9351db8bb0b92eb2d26af1b8f7f"meta-systemd      = "master:47f7d287a09329734629cb9d194ef4e077117d79"
Specifically, it built for the qemux86, qemux86-64 and hasell-wc machines.
I have successfully run my own python3 service, which uses python3 dbus and GObject from gi.repository.
I have also inherited gobject-introspection into modemmanager_1.4.2.bb from meta-oe, which fixed the recipe building and I have checked that the target executable runs but not tested its dbus interface yet.
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2008 bytes --]

Re: gobject introspection to oe-core

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On 17 December 2015 at 09:16, Chris Trobridge <christrobridge@hotmail.com>
wrote:

> I have successfully run my own python3 service, which uses python3 dbus
> and GObject from gi.repository.
>

Thanks for the feedback, it's much appreciated.

Ross

[-- Attachment #2: Type: text/html, Size: 632 bytes --]

Re: gobject introspection to oe-core

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

One thing I failed to mention when I reported on this previously is that I needed to patch polkit_0.113.bb:
-DEPENDS = "expat glib-2.0 intltool-native gobject-introspection-stub mozjs"+DEPENDS = "expat glib-2.0 intltool-native gobject-introspection mozjs"
This seems quite obvious, so I am sure you're aware of it.  That was all I needed but there are other references to gobject-introspection-stub in:
meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bbmeta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bbmeta-oe/recipes-devtools/libgee/libgee_0.16.1.bbmeta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bbmeta-oe/recipes-support/upower/upower_0.9.14.bb
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1370 bytes --]

Re: gobject introspection to oe-core

[Alexander Kanavin]

On 02/09/2016 12:30 PM, Chris Trobridge wrote:
> One thing I failed to mention when I reported on this previously is that
> I needed to patch polkit_0.113.bb:
>
> -DEPENDS = "expat glib-2.0 intltool-native gobject-introspection-stub mozjs"
> +DEPENDS = "expat glib-2.0 intltool-native gobject-introspection mozjs"
>
> This seems quite obvious, so I am sure you're aware of it.  That was all
> I needed but there are other references to gobject-introspection-stub in:
>
> meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bb
> meta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bb
> meta-oe/recipes-devtools/libgee/libgee_0.16.1.bb
> meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb
> meta-oe/recipes-support/upower/upower_0.9.14.bb

Those recipes are all in meta-oe - fixing them is not in scope at the 
moment. For now the introspection patchset is strictly for oe-core.

You are welcome to develop and maintain a companion meta-oe patchset though.

Alex

Re: gobject introspection to oe-core

[alexander.kanavin]

>> meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bb
>> meta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bb
>> meta-oe/recipes-devtools/libgee/libgee_0.16.1.bb
>> meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb
>> meta-oe/recipes-support/upower/upower_0.9.14.bb
>
> Those recipes are all in meta-oe - fixing them is not in scope at the
moment. For now the introspection patchset is strictly for oe-core.
>
> You are welcome to develop and maintain a companion meta-oe patchset
though.

Actually, scratch that. I realized that I'm probably the most qualified to
do this, and if I don't, there will be maintainer fury when introspection
lands in oe-core and dozens of recipes in meta-oe break. So without
further ado, here's the initial introspection patchset for meta-oe, which
you are welcome to try and test:
http://git.openembedded.org/meta-openembedded-contrib/log/?h=akanavin/gobject-introspection-fixes

Cheers,
Alex

Re: gobject introspection to oe-core

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

This is very interesting. Once gobject introspection is in place, vala 
based software like Rygel can finally be compiled directly from the vala 
source, which makes it much easier to apply patches against it.
Also, I think the GStreamer 1.0 Python bindings need GIR. This recipe 
could then be reintroduced (it was there, but got removed).

On 2015-12-17 10:16, Chris Trobridge wrote:
> Hi,
>
> I have done some testing of Alex's branch 
> "akanavin/gobject-introspection-experimental", originally 
> http://patchwork.openembedded.org/patch/107089/ 
> <http://patchwork.openembedded.org/patch/107089/%0A><http://patchwork.openembedded.org/patch/107089/%0A>
>
> I have built this successfully for x86 and x64 targets on an x64 build 
> machine:
>
> meta
> meta-yocto
> meta-yocto-bsp    = 
> "akanavin/gobject-introspection-experimental:04c7746ce90abc14604dec3328b9472c53cccf98"
> meta-networking
> meta-oe
> meta-python       = "master:47f7d287a09329734629cb9d194ef4e077117d79"
> meta-haswell-wc
> meta-intel        = "master:6e91701dcf68f9351db8bb0b92eb2d26af1b8f7f"
> meta-systemd      = "master:47f7d287a09329734629cb9d194ef4e077117d79"
>
> Specifically, it built for the qemux86, qemux86-64 and hasell-wc machines.
>
> I have successfully run my own python3 service, which uses python3 
> dbus and GObject from gi.repository.
>
> I have also inherited gobject-introspection into modemmanager_1.4.2.bb 
> from meta-oe, which fixed the recipe building and I have checked that 
> the target executable runs but not tested its dbus interface yet.
>
> Regards,
> Chris
>
>
>


[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

Re: gobject introspection to oe-core

[Alexander Kanavin]

On 02/09/2016 12:52 PM, Carlos Rafael Giani wrote:
> This is very interesting. Once gobject introspection is in place, vala
> based software like Rygel can finally be compiled directly from the vala
> source, which makes it much easier to apply patches against it.
> Also, I think the GStreamer 1.0 Python bindings need GIR. This recipe
> could then be reintroduced (it was there, but got removed).

Gstreamer Python bindings are not real bindings as such - they are a few 
tweaks and overrides on top of standard Python's support for 
introspection (which provided by pygobject), and they also add support 
for writing gstreamer elements in python.

Generally, nowadays any support for GLib-based software in language 
environments other than C or C++ is provided only through introspection.

If you want to write your software in anything else than C or C++, and 
you want to use gstreamer, webkit, gtk, glib's dbus support, etc., you 
have to have introspection working:
https://wiki.gnome.org/Projects/GObjectIntrospection/Users


Alex