the fate of Vala in OE

the fate of Vala in OE

[Alexander Kanavin]

Hello,

I'd like to propose the removal of Vala recipe and support for 
generating Vala bindings from oe-core. The only software that is written 
in Vala and makes sense in embedded environment is Rygel (an 
implementation of various UPnP AV services), and even that can be 
compiled from intermediate C sources without a need for Vala compiler or 
bindings. The only benefit from compiling from Vala source would be that 
Rygel could be more easily patched - and I think that doesn't really 
justify maintaining the full Vala stack.

Thoughts?

Alex

Re: [oe] the fate of Vala in OE

[Philip Balister]

On 06/09/2016 06:28 AM, Alexander Kanavin wrote:
> Hello,
> 
> I'd like to propose the removal of Vala recipe and support for
> generating Vala bindings from oe-core. The only software that is written
> in Vala and makes sense in embedded environment is Rygel (an

It seems that there are use cases beyond just embedded systems for
OpenEmbedded, so this logic is not really valid. See:

http://openxt.org/

And yes, I think it is useful for openembedded-core to have as broad an
audience as possible.

That said, what other layers use vala? If it leaves core, is there a
layer that can host it and support other layers using it without to much
trouble?

Philip

> implementation of various UPnP AV services), and even that can be
> compiled from intermediate C sources without a need for Vala compiler or
> bindings. The only benefit from compiling from Vala source would be that
> Rygel could be more easily patched - and I think that doesn't really
> justify maintaining the full Vala stack.
> 
> Thoughts?
> 
> Alex

Re: the fate of Vala in OE

[Philip Balister]

On 06/09/2016 06:28 AM, Alexander Kanavin wrote:
> Hello,
> 
> I'd like to propose the removal of Vala recipe and support for
> generating Vala bindings from oe-core. The only software that is written
> in Vala and makes sense in embedded environment is Rygel (an

It seems that there are use cases beyond just embedded systems for
OpenEmbedded, so this logic is not really valid. See:

http://openxt.org/

And yes, I think it is useful for openembedded-core to have as broad an
audience as possible.

That said, what other layers use vala? If it leaves core, is there a
layer that can host it and support other layers using it without to much
trouble?

Philip

> implementation of various UPnP AV services), and even that can be
> compiled from intermediate C sources without a need for Vala compiler or
> bindings. The only benefit from compiling from Vala source would be that
> Rygel could be more easily patched - and I think that doesn't really
> justify maintaining the full Vala stack.
> 
> Thoughts?
> 
> Alex

Re: [oe] the fate of Vala in OE

[Burton, Ross]

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

On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:

> That said, what other layers use vala? If it leaves core, is there a
> layer that can host it and support other layers using it without to much
> trouble?
>

That's the key question really - can the support be extracted and added to
eg meta-vala in some way?

Ross

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

Re: [OE-core] the fate of Vala in OE

[Burton, Ross]

On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:

> That said, what other layers use vala? If it leaves core, is there a
> layer that can host it and support other layers using it without to much
> trouble?
>

That's the key question really - can the support be extracted and added to
eg meta-vala in some way?

Ross

Re: [oe] the fate of Vala in OE

[timothy.t.orling]

> On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:
>
>> That said, what other layers use vala? If it leaves core, is there a
>> layer that can host it and support other layers using it without to much
>> trouble?
>>
>
> That's the key question really - can the support be extracted and added to
> eg meta-vala in some way?
>
> Ross

I use vala for clutter/cogl/weston/wayland development, although not in
any published public layers. Part of me hates to see it leave core, but a
well maintained layer is acceptable-ish. I know that vala-terminal in
meta-oe has been in and out of blacklist for quite a while now.

Cheers.

--Tim

Re: [OE-core] the fate of Vala in OE

[timothy.t.orling]

> On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:
>
>> That said, what other layers use vala? If it leaves core, is there a
>> layer that can host it and support other layers using it without to much
>> trouble?
>>
>
> That's the key question really - can the support be extracted and added to
> eg meta-vala in some way?
>
> Ross

I use vala for clutter/cogl/weston/wayland development, although not in
any published public layers. Part of me hates to see it leave core, but a
well maintained layer is acceptable-ish. I know that vala-terminal in
meta-oe has been in and out of blacklist for quite a while now.

Cheers.

--Tim

Re: [oe] the fate of Vala in OE

[Petr Nechaev]

We do use Vala for internal gstreamer-related projects so I would
volunteer to support it in oe-core.
---
Petr


On Thu, Jun 9, 2016 at 11:56 AM,  <timothy.t.orling@linux.intel.com> wrote:
>> On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:
>>
>>> That said, what other layers use vala? If it leaves core, is there a
>>> layer that can host it and support other layers using it without to much
>>> trouble?
>>>
>>
>> That's the key question really - can the support be extracted and added to
>> eg meta-vala in some way?
>>
>> Ross
>
> I use vala for clutter/cogl/weston/wayland development, although not in
> any published public layers. Part of me hates to see it leave core, but a
> well maintained layer is acceptable-ish. I know that vala-terminal in
> meta-oe has been in and out of blacklist for quite a while now.
>
> Cheers.
>
> --Tim
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] the fate of Vala in OE

[Petr Nechaev]

We do use Vala for internal gstreamer-related projects so I would
volunteer to support it in oe-core.
---
Petr


On Thu, Jun 9, 2016 at 11:56 AM,  <timothy.t.orling@linux.intel.com> wrote:
>> On 9 June 2016 at 15:08, Philip Balister <philip@balister.org> wrote:
>>
>>> That said, what other layers use vala? If it leaves core, is there a
>>> layer that can host it and support other layers using it without to much
>>> trouble?
>>>
>>
>> That's the key question really - can the support be extracted and added to
>> eg meta-vala in some way?
>>
>> Ross
>
> I use vala for clutter/cogl/weston/wayland development, although not in
> any published public layers. Part of me hates to see it leave core, but a
> well maintained layer is acceptable-ish. I know that vala-terminal in
> meta-oe has been in and out of blacklist for quite a while now.
>
> Cheers.
>
> --Tim
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [oe] the fate of Vala in OE

[Burton, Ross]

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

On 9 June 2016 at 16:59, Petr Nechaev <petr.nechaev@cogentembedded.com>
wrote:

> We do use Vala for internal gstreamer-related projects so I would
> volunteer to support it in oe-core.
>

Would you volunteer to maintain it in a separate layer if possible?  If
nothing in core uses it and it can be maintained out of core then I think
it should be moved out.  Currently, vala support is in oe-core but nothing
in oe-core uses it... so the autobuilder can't tell if it works.

Ross

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

Re: [OE-core] the fate of Vala in OE

[Burton, Ross]

On 9 June 2016 at 16:59, Petr Nechaev <petr.nechaev@cogentembedded.com>
wrote:

> We do use Vala for internal gstreamer-related projects so I would
> volunteer to support it in oe-core.
>

Would you volunteer to maintain it in a separate layer if possible?  If
nothing in core uses it and it can be maintained out of core then I think
it should be moved out.  Currently, vala support is in oe-core but nothing
in oe-core uses it... so the autobuilder can't tell if it works.

Ross

Re: [oe] the fate of Vala in OE

[Martin Jansa]

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

On Thu, Jun 09, 2016 at 05:36:32PM +0100, Burton, Ross wrote:
> On 9 June 2016 at 16:59, Petr Nechaev <petr.nechaev@cogentembedded.com>
> wrote:
> 
> > We do use Vala for internal gstreamer-related projects so I would
> > volunteer to support it in oe-core.
> >
> 
> Would you volunteer to maintain it in a separate layer if possible?  If
> nothing in core uses it and it can be maintained out of core then I think
> it should be moved out.  Currently, vala support is in oe-core but nothing
> in oe-core uses it... so the autobuilder can't tell if it works.

It's used by couple recipes in meta-oe and other layers which already
depend on meta-oe:
meta-multimedia, meta-gnome, meta-efl, meta-fso

so if you want to move it out from oe-core, then it should be returned
to meta-oe (from where it was moved to oe-core a while back with midori):

commit 6f642a51dc98b0a8a20b2d0a6bfe6917e9f2091f
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date:   Wed Aug 28 10:43:25 2013 +0000

    classes/vala: remove
    
    This is now in OE-Core as of 807285c751862aaa775db5a13293007bfb3c29df.
    
    Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

commit ad185f4494fff1254bfa167d6715db7be5a2de04
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date:   Wed Aug 28 10:43:24 2013 +0000

    vala: remove
    
    This is now in OE-Core as of 649b48557d8702daaf4f28482848ab0b07abed83.
    
    Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [OE-core] the fate of Vala in OE

[Martin Jansa]

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

On Thu, Jun 09, 2016 at 05:36:32PM +0100, Burton, Ross wrote:
> On 9 June 2016 at 16:59, Petr Nechaev <petr.nechaev@cogentembedded.com>
> wrote:
> 
> > We do use Vala for internal gstreamer-related projects so I would
> > volunteer to support it in oe-core.
> >
> 
> Would you volunteer to maintain it in a separate layer if possible?  If
> nothing in core uses it and it can be maintained out of core then I think
> it should be moved out.  Currently, vala support is in oe-core but nothing
> in oe-core uses it... so the autobuilder can't tell if it works.

It's used by couple recipes in meta-oe and other layers which already
depend on meta-oe:
meta-multimedia, meta-gnome, meta-efl, meta-fso

so if you want to move it out from oe-core, then it should be returned
to meta-oe (from where it was moved to oe-core a while back with midori):

commit 6f642a51dc98b0a8a20b2d0a6bfe6917e9f2091f
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date:   Wed Aug 28 10:43:25 2013 +0000

    classes/vala: remove
    
    This is now in OE-Core as of 807285c751862aaa775db5a13293007bfb3c29df.
    
    Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

commit ad185f4494fff1254bfa167d6715db7be5a2de04
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date:   Wed Aug 28 10:43:24 2013 +0000

    vala: remove
    
    This is now in OE-Core as of 649b48557d8702daaf4f28482848ab0b07abed83.
    
    Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [oe] the fate of Vala in OE

[Petr Nechaev]

I can see that libsecret in oe-core depends on vala though for testing only.

If moving to meta-oe is community's decision, I will prepare the patch.

Re: [OE-core] the fate of Vala in OE

[Petr Nechaev]

I can see that libsecret in oe-core depends on vala though for testing only.

If moving to meta-oe is community's decision, I will prepare the patch.

Re: [OE-core] the fate of Vala in OE

[Gary Thomas]

On 2016-06-10 02:04, Petr Nechaev wrote:
> I can see that libsecret in oe-core depends on vala though for testing only.
>
> If moving to meta-oe is community's decision, I will prepare the patch.
>

It looks like a lot of things need vala (or more precisely vala-native).
I just tried a build which included meta-browser (I know this isn't OE-core
but _is_ very common) and saw this dependency chain:
"vala-native" -> "libxslt-native" [style=solid]
"vala-native" -> "glib-2.0-native" [style=solid]
"vala-native" -> "autoconf-native" [style=solid]
"vala-native" -> "automake-native" [style=solid]
"vala-native" -> "libtool-native" [style=solid]
"vala-native" -> "gnu-config-native" [style=solid]
"vala-native" -> "pkgconfig-native" [style=solid]
"vala-native" -> "flex-native" [style=solid]
"vala-native" -> "bison-native" [style=solid]

In this case, I think vala (vala-native) deserves OE-core status.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [OE-core] the fate of Vala in OE

[Martin Jansa]

You're reading it from wrong side.

This shows what vala-native needs, not what needs vala-native.

On Fri, Jun 10, 2016 at 10:35 AM, Gary Thomas <gary@mlbassoc.com> wrote:

> On 2016-06-10 02:04, Petr Nechaev wrote:
>
>> I can see that libsecret in oe-core depends on vala though for testing
>> only.
>>
>> If moving to meta-oe is community's decision, I will prepare the patch.
>>
>>
> It looks like a lot of things need vala (or more precisely vala-native).
> I just tried a build which included meta-browser (I know this isn't OE-core
> but _is_ very common) and saw this dependency chain:
> "vala-native" -> "libxslt-native" [style=solid]
> "vala-native" -> "glib-2.0-native" [style=solid]
> "vala-native" -> "autoconf-native" [style=solid]
> "vala-native" -> "automake-native" [style=solid]
> "vala-native" -> "libtool-native" [style=solid]
> "vala-native" -> "gnu-config-native" [style=solid]
> "vala-native" -> "pkgconfig-native" [style=solid]
> "vala-native" -> "flex-native" [style=solid]
> "vala-native" -> "bison-native" [style=solid]
>
> In this case, I think vala (vala-native) deserves OE-core status.
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [OE-core] the fate of Vala in OE

[Gary Thomas]

On 2016-06-10 10:41, Martin Jansa wrote:
> You're reading it from wrong side.
>
> This shows what vala-native needs, not what needs vala-native.

Yes, I realized that :-(

The actual list is smaller, but still important:
"gcr" -> "vala-native" [style=solid]
"gcr" -> "vala" [style=solid]
"libsecret" -> "vala-native" [style=solid]
"libsecret" -> "vala" [style=solid]

Both of those packages are in OE-core (meta/recipes-gnome)

>
> On Fri, Jun 10, 2016 at 10:35 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>
>> On 2016-06-10 02:04, Petr Nechaev wrote:
>>
>>> I can see that libsecret in oe-core depends on vala though for testing
>>> only.
>>>
>>> If moving to meta-oe is community's decision, I will prepare the patch.
>>>
>>>
>> It looks like a lot of things need vala (or more precisely vala-native).
>> I just tried a build which included meta-browser (I know this isn't OE-core
>> but _is_ very common) and saw this dependency chain:
>> "vala-native" -> "libxslt-native" [style=solid]
>> "vala-native" -> "glib-2.0-native" [style=solid]
>> "vala-native" -> "autoconf-native" [style=solid]
>> "vala-native" -> "automake-native" [style=solid]
>> "vala-native" -> "libtool-native" [style=solid]
>> "vala-native" -> "gnu-config-native" [style=solid]
>> "vala-native" -> "pkgconfig-native" [style=solid]
>> "vala-native" -> "flex-native" [style=solid]
>> "vala-native" -> "bison-native" [style=solid]
>>
>> In this case, I think vala (vala-native) deserves OE-core status.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/10/2016 01:10 PM, Gary Thomas wrote:

>
> Yes, I realized that :-(
>
> The actual list is smaller, but still important:
> "gcr" -> "vala-native" [style=solid]
> "gcr" -> "vala" [style=solid]
> "libsecret" -> "vala-native" [style=solid]
> "libsecret" -> "vala" [style=solid]
>
> Both of those packages are in OE-core (meta/recipes-gnome)

These packages are libraries, and need vala only for generating vala 
bindings for their library APIs. If there are no users of those 
bindings, then vala dependencies could be easily disabled.

The actual things in oe-core and meta-oe that truly need vala are Rygel 
and vala-terminal.


Alex

Re: [oe] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 07:36 PM, Burton, Ross wrote:

>     We do use Vala for internal gstreamer-related projects so I would
>     volunteer to support it in oe-core.
>
>
> Would you volunteer to maintain it in a separate layer if possible?  If
> nothing in core uses it and it can be maintained out of core then I
> think it should be moved out.  Currently, vala support is in oe-core but
> nothing in oe-core uses it... so the autobuilder can't tell if it works.

How about?

1) vala compiler recipe and support for generating library bindings 
stays in oe-core

2) we take care of updating the vala recipe to latest stable upstream 
version

3) we make sure that vala recipe builds correctly and library bindings 
are generated without error for libraries that are in oe-core

4) any other issues, such as compiler not working properly, or issues 
with bindings for things that are not in oe-core are handled by 'the 
community'.



Alex

Re: [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 07:36 PM, Burton, Ross wrote:

>     We do use Vala for internal gstreamer-related projects so I would
>     volunteer to support it in oe-core.
>
>
> Would you volunteer to maintain it in a separate layer if possible?  If
> nothing in core uses it and it can be maintained out of core then I
> think it should be moved out.  Currently, vala support is in oe-core but
> nothing in oe-core uses it... so the autobuilder can't tell if it works.

How about?

1) vala compiler recipe and support for generating library bindings 
stays in oe-core

2) we take care of updating the vala recipe to latest stable upstream 
version

3) we make sure that vala recipe builds correctly and library bindings 
are generated without error for libraries that are in oe-core

4) any other issues, such as compiler not working properly, or issues 
with bindings for things that are not in oe-core are handled by 'the 
community'.



Alex

Re: [oe] the fate of Vala in OE

[Tim Orling]

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

On Fri, Jun 10, 2016 at 6:21 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 06/09/2016 07:36 PM, Burton, Ross wrote:
>
>     We do use Vala for internal gstreamer-related projects so I would
>>     volunteer to support it in oe-core.
>>
>>
>> Would you volunteer to maintain it in a separate layer if possible?  If
>> nothing in core uses it and it can be maintained out of core then I
>> think it should be moved out.  Currently, vala support is in oe-core but
>> nothing in oe-core uses it... so the autobuilder can't tell if it works.
>>
>
> How about?
>
> 1) vala compiler recipe and support for generating library bindings stays
> in oe-core
>
> 2) we take care of updating the vala recipe to latest stable upstream
> version
>
> 3) we make sure that vala recipe builds correctly and library bindings are
> generated without error for libraries that are in oe-core
>
> 4) any other issues, such as compiler not working properly, or issues with
> bindings for things that are not in oe-core are handled by 'the community'.
>
>
Excellent compromise. I volunteer to help with that.
 --Tim

>
>
> Alex
>
>

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

Re: [OE-core] the fate of Vala in OE

[Tim Orling]

On Fri, Jun 10, 2016 at 6:21 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 06/09/2016 07:36 PM, Burton, Ross wrote:
>
>     We do use Vala for internal gstreamer-related projects so I would
>>     volunteer to support it in oe-core.
>>
>>
>> Would you volunteer to maintain it in a separate layer if possible?  If
>> nothing in core uses it and it can be maintained out of core then I
>> think it should be moved out.  Currently, vala support is in oe-core but
>> nothing in oe-core uses it... so the autobuilder can't tell if it works.
>>
>
> How about?
>
> 1) vala compiler recipe and support for generating library bindings stays
> in oe-core
>
> 2) we take care of updating the vala recipe to latest stable upstream
> version
>
> 3) we make sure that vala recipe builds correctly and library bindings are
> generated without error for libraries that are in oe-core
>
> 4) any other issues, such as compiler not working properly, or issues with
> bindings for things that are not in oe-core are handled by 'the community'.
>
>
Excellent compromise. I volunteer to help with that.
 --Tim

>
>
> Alex
>
>

Re: [oe] the fate of Vala in OE

[Khem Raj]

On Fri, Jun 10, 2016 at 6:21 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 06/09/2016 07:36 PM, Burton, Ross wrote:
>
>>     We do use Vala for internal gstreamer-related projects so I would
>>     volunteer to support it in oe-core.
>>
>>
>> Would you volunteer to maintain it in a separate layer if possible?  If
>> nothing in core uses it and it can be maintained out of core then I
>> think it should be moved out.  Currently, vala support is in oe-core but
>> nothing in oe-core uses it... so the autobuilder can't tell if it works.
>
>
> How about?
>
> 1) vala compiler recipe and support for generating library bindings stays in
> oe-core
>
> 2) we take care of updating the vala recipe to latest stable upstream
> version
>
> 3) we make sure that vala recipe builds correctly and library bindings are
> generated without error for libraries that are in oe-core
>
> 4) any other issues, such as compiler not working properly, or issues with
> bindings for things that are not in oe-core are handled by 'the community'.
>

We need some ptests to verify vala, so keeping some apps for that would be good.

>
>
> Alex
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] the fate of Vala in OE

[Khem Raj]

On Fri, Jun 10, 2016 at 6:21 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 06/09/2016 07:36 PM, Burton, Ross wrote:
>
>>     We do use Vala for internal gstreamer-related projects so I would
>>     volunteer to support it in oe-core.
>>
>>
>> Would you volunteer to maintain it in a separate layer if possible?  If
>> nothing in core uses it and it can be maintained out of core then I
>> think it should be moved out.  Currently, vala support is in oe-core but
>> nothing in oe-core uses it... so the autobuilder can't tell if it works.
>
>
> How about?
>
> 1) vala compiler recipe and support for generating library bindings stays in
> oe-core
>
> 2) we take care of updating the vala recipe to latest stable upstream
> version
>
> 3) we make sure that vala recipe builds correctly and library bindings are
> generated without error for libraries that are in oe-core
>
> 4) any other issues, such as compiler not working properly, or issues with
> bindings for things that are not in oe-core are handled by 'the community'.
>

We need some ptests to verify vala, so keeping some apps for that would be good.

>
>
> Alex
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 05:37 PM, Burton, Ross wrote:

>> That said, what other layers use vala? If it leaves core, is there a
>> layer that can host it and support other layers using it without to much
>> trouble?
>>
>
> That's the key question really - can the support be extracted and added to
> eg meta-vala in some way?

The problem with such extraction is that for recipes in oe-core support 
for generating their vala bindings still has to be provided. I don't see 
a way to do that that is not overly complicated (in 'opaque side 
effects' kind of way) and difficult to grasp for humans.


Alex

Re: [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 05:08 PM, Philip Balister wrote:

> It seems that there are use cases beyond just embedded systems for
> OpenEmbedded, so this logic is not really valid. See:
>
> http://openxt.org/
>
> And yes, I think it is useful for openembedded-core to have as broad an
> audience as possible.

Our resources are limited, so there has to be specific evidence for a 
need for Vala; not the vague 'it could be useful to someone out there' 
kind of thinking.

The reason I was proposing removing Vala is that:
a) you can count the open source software written in Vala on fingers of 
one hand: it's Rygel, Elementary OS apps, and a couple of 
desktop-oriented Gnome apps.
b) until yesterday, we haven't heard of any in-house usage of Vala by OE 
users.

But since people have spoken up, I'll make a different proposal in a moment.

> That said, what other layers use vala? If it leaves core, is there a
> layer that can host it and support other layers using it without to much
> trouble?

As far as oe-core and all of meta-oe layers go, it's Rygel and 
vala-terminal, that's all.

Alex

Re: the fate of Vala in OE

[Carlos Rafael Giani]

On 2016-06-09 12:28, Alexander Kanavin wrote:
> Hello,
>
> I'd like to propose the removal of Vala recipe and support for 
> generating Vala bindings from oe-core. The only software that is 
> written in Vala and makes sense in embedded environment is Rygel (an 
> implementation of various UPnP AV services), and even that can be 
> compiled from intermediate C sources without a need for Vala compiler 
> or bindings. The only benefit from compiling from Vala source would be 
> that Rygel could be more easily patched - and I think that doesn't 
> really justify maintaining the full Vala stack.
>
> Thoughts?
>
> Alex

The benefit of easy patching is considerable. If you only have the C 
sources, then the patches have to be done between versions of that 
generated C code. The resulting patches are often big and unreadable.

I was actually happy to see g-i added to OE-core so we can get rid of 
some custom C-source patches for Rygel and just patch the Vala code 
directly instead. Removing vala would nullify this benefit.