[Buildroot] [buildroot] libevas build failure analysis

[Buildroot] [buildroot] libevas build failure analysis

[arnaud aujon]

Hi there,

A quick analysis of libevas build failure (
http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/
)

The build fails because the member 'delete_me' of the Image_Entry_Flags
structure is undefined. This is because there is a ifdef
BUILD_ASYNC_PRELOAD surrounding this member which is not defined during the
build because the toolchain doesn't have thread support.

From libevas.mk :
# async image preload support needs threads support in toolchain
ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
LIBEVAS_CONF_OPT += --disable-async-preload
endif

But it seems like the file evas_cache2.c is using 'delete_me' regardless of
the 'async image preload support'

I don't have the time to investigate more, but it looks like without
threads we should use 'lib/cache' and not 'lib/cache2'  which are defining
the same symboles but 'cache2' absolutely need threads support, 'cache'
doesn't .
So I guess we have to fix the makefile to use this the 'cache'
implementation.

Does someone  know what we should do here ?

Regards,

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131128/384eca9c/attachment.html>

[Buildroot] [buildroot] libevas build failure analysis

[Lionel Orry]

Can you send an email on e-devel maiiling list? They are about to put
EFL 1.7 in maintenance as soon as 1.8 is released, so I guess it's
time to tell them, I'm sure they will correct it quickly


On Thu, Nov 28, 2013 at 8:04 PM, arnaud aujon <arnaud.aujon@gmail.com> wrote:
> Hi there,
>
> A quick analysis of libevas build failure
> (http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/)
>
> The build fails because the member 'delete_me' of the Image_Entry_Flags
> structure is undefined. This is because there is a ifdef BUILD_ASYNC_PRELOAD
> surrounding this member which is not defined during the build because the
> toolchain doesn't have thread support.
>
> From libevas.mk :
> # async image preload support needs threads support in toolchain
> ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> LIBEVAS_CONF_OPT += --disable-async-preload
> endif
>
> But it seems like the file evas_cache2.c is using 'delete_me' regardless of
> the 'async image preload support'
>
> I don't have the time to investigate more, but it looks like without threads
> we should use 'lib/cache' and not 'lib/cache2'  which are defining the same
> symboles but 'cache2' absolutely need threads support, 'cache' doesn't .
> So I guess we have to fix the makefile to use this the 'cache'
> implementation.
>
> Does someone  know what we should do here ?
>
> Regards,
>
> Arnaud
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [buildroot] libevas build failure analysis

[arnaud aujon]

Ok, the problem has been reported to the dev ML, I will follow this.

Regards,

Arnaud


2013/11/28 Lionel Orry <lionel.orry@gmail.com>

> Can you send an email on e-devel maiiling list? They are about to put
> EFL 1.7 in maintenance as soon as 1.8 is released, so I guess it's
> time to tell them, I'm sure they will correct it quickly
>
>
> On Thu, Nov 28, 2013 at 8:04 PM, arnaud aujon <arnaud.aujon@gmail.com>
> wrote:
> > Hi there,
> >
> > A quick analysis of libevas build failure
> > (
> http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/
> )
> >
> > The build fails because the member 'delete_me' of the Image_Entry_Flags
> > structure is undefined. This is because there is a ifdef
> BUILD_ASYNC_PRELOAD
> > surrounding this member which is not defined during the build because the
> > toolchain doesn't have thread support.
> >
> > From libevas.mk :
> > # async image preload support needs threads support in toolchain
> > ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> > LIBEVAS_CONF_OPT += --disable-async-preload
> > endif
> >
> > But it seems like the file evas_cache2.c is using 'delete_me' regardless
> of
> > the 'async image preload support'
> >
> > I don't have the time to investigate more, but it looks like without
> threads
> > we should use 'lib/cache' and not 'lib/cache2'  which are defining the
> same
> > symboles but 'cache2' absolutely need threads support, 'cache' doesn't .
> > So I guess we have to fix the makefile to use this the 'cache'
> > implementation.
> >
> > Does someone  know what we should do here ?
> >
> > Regards,
> >
> > Arnaud
> >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131128/6ef393f2/attachment.html>

[Buildroot] [buildroot] libevas build failure analysis

[arnaud aujon]

Hi,

I got an answer from upstream, they said threads are mandatory in 1.8
release, don't know yet about our current 1.7.7, do we have any plan
bumping to 1.8 ?


2013/11/28 arnaud aujon <arnaud.aujon@gmail.com>

> Ok, the problem has been reported to the dev ML, I will follow this.
>
> Regards,
>
> Arnaud
>
>
> 2013/11/28 Lionel Orry <lionel.orry@gmail.com>
>
>> Can you send an email on e-devel maiiling list? They are about to put
>> EFL 1.7 in maintenance as soon as 1.8 is released, so I guess it's
>> time to tell them, I'm sure they will correct it quickly
>>
>>
>> On Thu, Nov 28, 2013 at 8:04 PM, arnaud aujon <arnaud.aujon@gmail.com>
>> wrote:
>> > Hi there,
>> >
>> > A quick analysis of libevas build failure
>> > (
>> http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/
>> )
>> >
>> > The build fails because the member 'delete_me' of the Image_Entry_Flags
>> > structure is undefined. This is because there is a ifdef
>> BUILD_ASYNC_PRELOAD
>> > surrounding this member which is not defined during the build because
>> the
>> > toolchain doesn't have thread support.
>> >
>> > From libevas.mk :
>> > # async image preload support needs threads support in toolchain
>> > ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
>> > LIBEVAS_CONF_OPT += --disable-async-preload
>> > endif
>> >
>> > But it seems like the file evas_cache2.c is using 'delete_me'
>> regardless of
>> > the 'async image preload support'
>> >
>> > I don't have the time to investigate more, but it looks like without
>> threads
>> > we should use 'lib/cache' and not 'lib/cache2'  which are defining the
>> same
>> > symboles but 'cache2' absolutely need threads support, 'cache' doesn't .
>> > So I guess we have to fix the makefile to use this the 'cache'
>> > implementation.
>> >
>> > Does someone  know what we should do here ?
>> >
>> > Regards,
>> >
>> > Arnaud
>> >
>> >
>> > _______________________________________________
>> > buildroot mailing list
>> > buildroot at busybox.net
>> > http://lists.busybox.net/mailman/listinfo/buildroot
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131203/70f46be7/attachment-0001.html>

[Buildroot] [buildroot] libevas build failure analysis

[Lionel Orry]

Hi,

On Tue, Dec 3, 2013 at 9:32 AM, arnaud aujon <arnaud.aujon@gmail.com> wrote:
> Hi,
>
> I got an answer from upstream, they said threads are mandatory in 1.8
> release, don't know yet about our current 1.7.7, do we have any plan bumping
> to 1.8 ?
>

They just released the 1.8 version, I think it's time to think about
the bump, but there are some quite fundamental changes between 1.7 and
1.8 (most noticeable one is the merged tree instead of separate source
code for core libraries), and the bump is probably not that easy at
first, and then, I also suppose there are some applications that may
still need 1.7 among buildroot users.

I would then suggest to have EFL 1.7 and EFL 1.8 in parallel for some
time. Maybe we should create efl18 package.

As for EFL 1.7, maybe the easiest to do is require a toolchain with
threads support.

What do you think ?

>
> 2013/11/28 arnaud aujon <arnaud.aujon@gmail.com>
>>
>> Ok, the problem has been reported to the dev ML, I will follow this.
>>
>> Regards,
>>
>> Arnaud
>>
>>
>> 2013/11/28 Lionel Orry <lionel.orry@gmail.com>
>>>
>>> Can you send an email on e-devel maiiling list? They are about to put
>>> EFL 1.7 in maintenance as soon as 1.8 is released, so I guess it's
>>> time to tell them, I'm sure they will correct it quickly
>>>
>>>
>>> On Thu, Nov 28, 2013 at 8:04 PM, arnaud aujon <arnaud.aujon@gmail.com>
>>> wrote:
>>> > Hi there,
>>> >
>>> > A quick analysis of libevas build failure
>>> >
>>> > (http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/)
>>> >
>>> > The build fails because the member 'delete_me' of the Image_Entry_Flags
>>> > structure is undefined. This is because there is a ifdef
>>> > BUILD_ASYNC_PRELOAD
>>> > surrounding this member which is not defined during the build because
>>> > the
>>> > toolchain doesn't have thread support.
>>> >
>>> > From libevas.mk :
>>> > # async image preload support needs threads support in toolchain
>>> > ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
>>> > LIBEVAS_CONF_OPT += --disable-async-preload
>>> > endif
>>> >
>>> > But it seems like the file evas_cache2.c is using 'delete_me'
>>> > regardless of
>>> > the 'async image preload support'
>>> >
>>> > I don't have the time to investigate more, but it looks like without
>>> > threads
>>> > we should use 'lib/cache' and not 'lib/cache2'  which are defining the
>>> > same
>>> > symboles but 'cache2' absolutely need threads support, 'cache' doesn't
>>> > .
>>> > So I guess we have to fix the makefile to use this the 'cache'
>>> > implementation.
>>> >
>>> > Does someone  know what we should do here ?
>>> >
>>> > Regards,
>>> >
>>> > Arnaud
>>> >
>>> >
>>> > _______________________________________________
>>> > buildroot mailing list
>>> > buildroot at busybox.net
>>> > http://lists.busybox.net/mailman/listinfo/buildroot
>>
>>
>

Cheers
Lionel

[Buildroot] [buildroot] libevas build failure analysis

[arnaud aujon]

About adding a requirement to have a toolchain with thread support,is there
any chips/boards that can't have thread support in their toolchain ?

And as you said, I guess have EFL 1.7 and 1.8 for some time is a good idea.


2013/12/3 Lionel Orry <lionel.orry@gmail.com>

> Hi,
>
> On Tue, Dec 3, 2013 at 9:32 AM, arnaud aujon <arnaud.aujon@gmail.com>
> wrote:
> > Hi,
> >
> > I got an answer from upstream, they said threads are mandatory in 1.8
> > release, don't know yet about our current 1.7.7, do we have any plan
> bumping
> > to 1.8 ?
> >
>
> They just released the 1.8 version, I think it's time to think about
> the bump, but there are some quite fundamental changes between 1.7 and
> 1.8 (most noticeable one is the merged tree instead of separate source
> code for core libraries), and the bump is probably not that easy at
> first, and then, I also suppose there are some applications that may
> still need 1.7 among buildroot users.
>
> I would then suggest to have EFL 1.7 and EFL 1.8 in parallel for some
> time. Maybe we should create efl18 package.
>
> As for EFL 1.7, maybe the easiest to do is require a toolchain with
> threads support.
>
> What do you think ?
>
> >
> > 2013/11/28 arnaud aujon <arnaud.aujon@gmail.com>
> >>
> >> Ok, the problem has been reported to the dev ML, I will follow this.
> >>
> >> Regards,
> >>
> >> Arnaud
> >>
> >>
> >> 2013/11/28 Lionel Orry <lionel.orry@gmail.com>
> >>>
> >>> Can you send an email on e-devel maiiling list? They are about to put
> >>> EFL 1.7 in maintenance as soon as 1.8 is released, so I guess it's
> >>> time to tell them, I'm sure they will correct it quickly
> >>>
> >>>
> >>> On Thu, Nov 28, 2013 at 8:04 PM, arnaud aujon <arnaud.aujon@gmail.com>
> >>> wrote:
> >>> > Hi there,
> >>> >
> >>> > A quick analysis of libevas build failure
> >>> >
> >>> > (
> http://autobuild.buildroot.org/results/15c/15cfb974e428b20ba230321cd8b59a82308785af/
> )
> >>> >
> >>> > The build fails because the member 'delete_me' of the
> Image_Entry_Flags
> >>> > structure is undefined. This is because there is a ifdef
> >>> > BUILD_ASYNC_PRELOAD
> >>> > surrounding this member which is not defined during the build because
> >>> > the
> >>> > toolchain doesn't have thread support.
> >>> >
> >>> > From libevas.mk :
> >>> > # async image preload support needs threads support in toolchain
> >>> > ifneq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> >>> > LIBEVAS_CONF_OPT += --disable-async-preload
> >>> > endif
> >>> >
> >>> > But it seems like the file evas_cache2.c is using 'delete_me'
> >>> > regardless of
> >>> > the 'async image preload support'
> >>> >
> >>> > I don't have the time to investigate more, but it looks like without
> >>> > threads
> >>> > we should use 'lib/cache' and not 'lib/cache2'  which are defining
> the
> >>> > same
> >>> > symboles but 'cache2' absolutely need threads support, 'cache'
> doesn't
> >>> > .
> >>> > So I guess we have to fix the makefile to use this the 'cache'
> >>> > implementation.
> >>> >
> >>> > Does someone  know what we should do here ?
> >>> >
> >>> > Regards,
> >>> >
> >>> > Arnaud
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > buildroot mailing list
> >>> > buildroot at busybox.net
> >>> > http://lists.busybox.net/mailman/listinfo/buildroot
> >>
> >>
> >
>
> Cheers
> Lionel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131203/2459b792/attachment.html>

[Buildroot] [buildroot] libevas build failure analysis

[Thomas Petazzoni]

Dear Lionel Orry,

On Tue, 3 Dec 2013 09:45:15 +0100, Lionel Orry wrote:

> They just released the 1.8 version, I think it's time to think about
> the bump, but there are some quite fundamental changes between 1.7 and
> 1.8 (most noticeable one is the merged tree instead of separate source
> code for core libraries), and the bump is probably not that easy at
> first, and then, I also suppose there are some applications that may
> still need 1.7 among buildroot users.

Are you sure 1.8 breaks the compatibility with 1.7 ? I don't think so.
It's not because in terms of source code everything is now inside a
single tarball that the compatibility for applications has been broken.

> I would then suggest to have EFL 1.7 and EFL 1.8 in parallel for some
> time. Maybe we should create efl18 package.

Before doing that, I'd like to understand how/why EFL 1.8 is
incompatible with EFL 1.7.

> As for EFL 1.7, maybe the easiest to do is require a toolchain with
> threads support.

I agree.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [buildroot] libevas build failure analysis

[Thomas Petazzoni]

Arnaud,

On Tue, 3 Dec 2013 10:13:52 +0100, arnaud aujon wrote:

> About adding a requirement to have a toolchain with thread support,is there
> any chips/boards that can't have thread support in their toolchain ?

Huh? Having thread support or not is not related to the underlying
hardware (i.e SoC or board). It's a software choice, at the C library
configuration level. So there is absolutely no problem in requiring
thread support for something relatively large such as EFL.

> And as you said, I guess have EFL 1.7 and 1.8 for some time is a good idea.

Why?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [buildroot] libevas build failure analysis

[Lionel Orry]

Dear Thomas,

On Wed, Dec 4, 2013 at 10:27 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Lionel Orry,
>
> On Tue, 3 Dec 2013 09:45:15 +0100, Lionel Orry wrote:
>
>> They just released the 1.8 version, I think it's time to think about
>> the bump, but there are some quite fundamental changes between 1.7 and
>> 1.8 (most noticeable one is the merged tree instead of separate source
>> code for core libraries), and the bump is probably not that easy at
>> first, and then, I also suppose there are some applications that may
>> still need 1.7 among buildroot users.
>
> Are you sure 1.8 breaks the compatibility with 1.7 ? I don't think so.
> It's not because in terms of source code everything is now inside a
> single tarball that the compatibility for applications has been broken.

That is true, I did not explain clearly the status. But I suppose I
can then convince you that a LOT of API changes occured by looking at
the NEWS file: https://git.enlightenment.org/core/efl.git/plain/NEWS?id=v1.8.1

Among other things, EFL 1.8 now has a mandatory dependency on bullet
library, which makes it much less suitable on light embedded systems ;
for example, I think bullet is not part of buildroot packages yet.

>
>> I would then suggest to have EFL 1.7 and EFL 1.8 in parallel for some
>> time. Maybe we should create efl18 package.
>
> Before doing that, I'd like to understand how/why EFL 1.8 is
> incompatible with EFL 1.7.

Your request is justified. See above about the API compatibility.

>
>> As for EFL 1.7, maybe the easiest to do is require a toolchain with
>> threads support.
>
> I agree.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

Best regards,
Lionel

[Buildroot] [buildroot] libevas build failure analysis

[Lucas De Marchi]

On Wed, Dec 4, 2013 at 8:24 AM, Lionel Orry <lionel.orry@gmail.com> wrote:
> Dear Thomas,
>
> On Wed, Dec 4, 2013 at 10:27 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Lionel Orry,
>>
>> On Tue, 3 Dec 2013 09:45:15 +0100, Lionel Orry wrote:
>>
>>> They just released the 1.8 version, I think it's time to think about
>>> the bump, but there are some quite fundamental changes between 1.7 and
>>> 1.8 (most noticeable one is the merged tree instead of separate source
>>> code for core libraries), and the bump is probably not that easy at
>>> first, and then, I also suppose there are some applications that may
>>> still need 1.7 among buildroot users.
>>
>> Are you sure 1.8 breaks the compatibility with 1.7 ? I don't think so.
>> It's not because in terms of source code everything is now inside a
>> single tarball that the compatibility for applications has been broken.

No, it doesn't break compatibility. If it did it would be called efl 2.x

There's a huge change in the underlying implementation of the object
model with the introduction of EO, but it should be API/ABI compatible
with EFL 1.7.

>
> That is true, I did not explain clearly the status. But I suppose I
> can then convince you that a LOT of API changes occured by looking at
> the NEWS file: https://git.enlightenment.org/core/efl.git/plain/NEWS?id=v1.8.1

APIs were added. Removals were made in a backward compatible manner.

>
> Among other things, EFL 1.8 now has a mandatory dependency on bullet
> library, which makes it much less suitable on light embedded systems ;
> for example, I think bullet is not part of buildroot packages yet.

that is not true. You can perfectly pass --disable-physics so the
dependency goes away.


Lucas De Marchi

[Buildroot] [buildroot] libevas build failure analysis

[Thomas Petazzoni]

Dear Lionel Orry,

On Wed, 4 Dec 2013 11:24:58 +0100, Lionel Orry wrote:

> That is true, I did not explain clearly the status. But I suppose I
> can then convince you that a LOT of API changes occured by looking at
> the NEWS file: https://git.enlightenment.org/core/efl.git/plain/NEWS?id=v1.8.1

I have just glanced through this file, but I only see a number of API
additions (so not something that breaks compatibility), a few
deprecations (but not removal). The only removal that I see are support
for some backends (such as the DirectFB backend).

Or do you have specific examples of API breakage between 1.7 and 1.8 ?

> Among other things, EFL 1.8 now has a mandatory dependency on bullet
> library, which makes it much less suitable on light embedded systems ;
> for example, I think bullet is not part of buildroot packages yet.

That's not a reason to keep an old version of EFL that is unmaintained
upstream. Let me explain why: Buildroot is here to package what
upstream provides. If in newer versions of a given upstream components
the choices that are made are not appropriate for embedded systems, or
to the taste of embedded Linux developers, then those developers should
work with upstream to resolve those issues, or fork the project to
create a new one. I don't think Buildroot should be keeping old
version of a given package, just because the new version has
new dependencies. If you don't like the new dependency on bullet, then
work with upstream to make it optional.

... some time looking at EFL 1.8.1 sources ...

In fact, my reading for EFL configure.ac is that the bullet library
dependency is only needed for the Ephysics component, which is a new
library in 1.8.x. Therefore, if you have an EFL 1.7 application, it
doesn't use Ephysics (because it didn't exist), and you can build EFL
1.8.x without Ephysics, and without the bullet dependency.

(Of course all those claims are completely untested, and only made on a
very quick reading of the EFL configure.ac script. Do not hesitate to
prove me wrong, or give more details.)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [buildroot] libevas build failure analysis

[Lionel Orry]

Dear Lucas and Thomas,

On Wed, Dec 4, 2013 at 1:21 PM, Lucas De Marchi
<lucas.de.marchi@gmail.com> wrote:
> On Wed, Dec 4, 2013 at 8:24 AM, Lionel Orry <lionel.orry@gmail.com> wrote:
>> Dear Thomas,
>>
>> On Wed, Dec 4, 2013 at 10:27 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Lionel Orry,
>>>
>>> On Tue, 3 Dec 2013 09:45:15 +0100, Lionel Orry wrote:
>>>
>>>> They just released the 1.8 version, I think it's time to think about
>>>> the bump, but there are some quite fundamental changes between 1.7 and
>>>> 1.8 (most noticeable one is the merged tree instead of separate source
>>>> code for core libraries), and the bump is probably not that easy at
>>>> first, and then, I also suppose there are some applications that may
>>>> still need 1.7 among buildroot users.
>>>
>>> Are you sure 1.8 breaks the compatibility with 1.7 ? I don't think so.
>>> It's not because in terms of source code everything is now inside a
>>> single tarball that the compatibility for applications has been broken.
>
> No, it doesn't break compatibility. If it did it would be called efl 2.x
>
> There's a huge change in the underlying implementation of the object
> model with the introduction of EO, but it should be API/ABI compatible
> with EFL 1.7.
>
>>
>> That is true, I did not explain clearly the status. But I suppose I
>> can then convince you that a LOT of API changes occured by looking at
>> the NEWS file: https://git.enlightenment.org/core/efl.git/plain/NEWS?id=v1.8.1
>
> APIs were added. Removals were made in a backward compatible manner.
>

Thank you Lucas for answering the thread as one of the core devs. I
saw a list of removals and did not think they could have been
backward-compatible. If they are, then I was just making noise, sorry.
You all did a great job with this release, I know that for sure.

>>
>> Among other things, EFL 1.8 now has a mandatory dependency on bullet
>> library, which makes it much less suitable on light embedded systems ;
>> for example, I think bullet is not part of buildroot packages yet.
>
> that is not true. You can perfectly pass --disable-physics so the
> dependency goes away.

I just checked actually, and I apologise for this again. I remember a
time when it was mandatory and did not notice it became optional.

>
>
> Lucas De Marchi

With kind regards,
Lionel

[Buildroot] [buildroot] libevas build failure analysis

[Lucas De Marchi]

On Wed, Dec 4, 2013 at 10:56 AM, Lionel Orry <lionel.orry@gmail.com> wrote:
> Dear Lucas and Thomas,
>
> On Wed, Dec 4, 2013 at 1:21 PM, Lucas De Marchi
> <lucas.de.marchi@gmail.com> wrote:
>> On Wed, Dec 4, 2013 at 8:24 AM, Lionel Orry <lionel.orry@gmail.com> wrote:
>>> Dear Thomas,
>>>
>>> On Wed, Dec 4, 2013 at 10:27 AM, Thomas Petazzoni
>>> <thomas.petazzoni@free-electrons.com> wrote:
>>>> Dear Lionel Orry,
>>>>
>>>> On Tue, 3 Dec 2013 09:45:15 +0100, Lionel Orry wrote:
>>>>
>>>>> They just released the 1.8 version, I think it's time to think about
>>>>> the bump, but there are some quite fundamental changes between 1.7 and
>>>>> 1.8 (most noticeable one is the merged tree instead of separate source
>>>>> code for core libraries), and the bump is probably not that easy at
>>>>> first, and then, I also suppose there are some applications that may
>>>>> still need 1.7 among buildroot users.
>>>>
>>>> Are you sure 1.8 breaks the compatibility with 1.7 ? I don't think so.
>>>> It's not because in terms of source code everything is now inside a
>>>> single tarball that the compatibility for applications has been broken.
>>
>> No, it doesn't break compatibility. If it did it would be called efl 2.x
>>
>> There's a huge change in the underlying implementation of the object
>> model with the introduction of EO, but it should be API/ABI compatible
>> with EFL 1.7.
>>
>>>
>>> That is true, I did not explain clearly the status. But I suppose I
>>> can then convince you that a LOT of API changes occured by looking at
>>> the NEWS file: https://git.enlightenment.org/core/efl.git/plain/NEWS?id=v1.8.1
>>
>> APIs were added. Removals were made in a backward compatible manner.
>>
>
> Thank you Lucas for answering the thread as one of the core devs. I
> saw a list of removals and did not think they could have been
> backward-compatible. If they are, then I was just making noise, sorry.
> You all did a great job with this release, I know that for sure.
>
>>>
>>> Among other things, EFL 1.8 now has a mandatory dependency on bullet
>>> library, which makes it much less suitable on light embedded systems ;
>>> for example, I think bullet is not part of buildroot packages yet.
>>
>> that is not true. You can perfectly pass --disable-physics so the
>> dependency goes away.
>
> I just checked actually, and I apologise for this again. I remember a
> time when it was mandatory and did not notice it became optional.

Indeed. No problem.

Lucas De Marchi