Re: [E-devel] Merging efl,eo and ecore

[Carsten H. (T. R. <ra...@ra...>]

On Fri, 29 Jul 2016 11:51:06 +0930 Simon Lees <sf...@su...> said:

> 
> 
> On 07/29/2016 11:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 29 Jul 2016 10:47:26 +0930 Simon Lees <sf...@su...> said:
> > 
> >>
> >>
> >> On 07/29/2016 10:11 AM, Cedric BAIL wrote:
> >>> On Thu, Jul 28, 2016 at 4:22 PM, Carsten Haitzler <ra...@ra...>
> >>> wrote:
> >>>> On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL <ced...@fr...>
> >>>> said:
> >>>>> I came to realize that splitting this 3 components don't really make
> >>>>> any more sense. If you want to build anything on top of efl, you are
> >>>>
> >>>> i totally agree. in fact if we are going to merge... we should do a lot
> >>>> more merging. we need to decide on a future much smaller set of libraries
> >>>>
> >>>> e.g. (lib* assumed)
> >>>>
> >>>> efl:
> >>>>   eina, eo, ecore, efl, eio
> >>>
> >>> I am not to found of merging eina in efl as eina in itself is useful
> >>> for a command line application that doesn't need a main loop and may
> >>> not even need eo. I am putting eet in that same category.
> >>>
> >>>> eflgui:
> >>>>   evas, edje, emotion, elementary, ector, ecore_audio, ecore_imf,
> >>>>   ecore_imf_evas, ecore_input
> >>>>
> >>>> eflnet:
> >>>>   ecore_con, ecore_ipc, eldbus, ecore_avahi
> >>>
> >>> I would argue that dbus is mostly used for UI and not network which is
> >>> why i see it in efl-gui.
> >>>
> >>>> eflsys:
> >>>>   ecore_file, efreet, efreet_mime, efreet_trash, elocation
> >>>
> >>> ecore_file should be a legacy only library and the missing feature of
> >>> eina and eio correctly extended to cover all use case. Obviously I
> >>> would see eio in this library.
> >>>
> >>>> others left over to figure out...
> >>>>   ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client
> >>>
> >>> embryo should be in efl-gui as it is only used by edje really. Not to
> >>> sure of the future of ethumb and if we do want to maintain our own
> >>> thumbnailer. ephysics could get merged in efl-gui I guess.
> >>>
> >>> eolian should be merged in efl actually as otherwise it kind of make
> >>> eo less useful especially if we want to compile the .eo file of efl
> >>> :-)
> >>>
> >>>> and definitely unportable or dubiously universal lib api's:
> >>>>   eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa, ecore_fb,
> >>>>   ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2, ecore_win32,
> >>>>   ecore_x, elput, escape, evil
> >>>
> >>> Do we even need to merge those ? They are not user facing normally
> >>> (well ok, some are used by enlightenment). This won't simplify much of
> >>> the API usage and won't really save that much memory. 40kb total if
> >>> merged, maybe ?
> >>>
> >>>> let's have a decent plan anyway first so we have a good idea where we are
> >>>> going.
> >>>>
> >>>>> now always going to link against those 3 libraries. Also as we push
> >>>>> for some more on efl interface, it become more obvious that efl and eo
> >>>>> are actually completely linked with ecore. As we were planning to
> >>>>> merge efl and eo anyway in 1.19, I am thinking we should actually go
> >>>>> one step further and directly merge with ecore.
> >>>>
> >>>> i think eina should merge in too to "libefl" and likely even eio and
> >>>> possibly even a chunk of ecore_file utility should be there either in eio
> >>>> or in eina - core file system interfaces.
> >>>
> >>> Well, if you are to merge eio in efl, there is no need for efl-sys I
> >>> think. I still believe eio should be in efl-sys and efl-sys exist. I
> >>> also think eina shouldn't be merged and same for eet, they have use in
> >>> standalone binary that need no main loop nor objects.
> >>>
> >>> Btw if we get agreement on this, I would like to do the merge right
> >>> away during efl 1.19 release cycle. Not just for efl, eo, ecore,
> >>> eolian merge, but for all of the above library merge.
> >>>
> >>
> >> Probably the best time to do the merge would be to call it efl 2.0,
> >> given that all the SO's are changing worrying about abi/api is much less
> >> of a issue, this would also be much less confusing. Even if that means
> >> its delayed to what would have been efl 1.21 or 1.22 I think that’s ok,
> >> I'm presuming at that point the eo based api would become the official
> >> api and the legacy api would remain but be depreciated (maybe i'm wrong
> >> there).
> > 
> > we're at least planning on HAVING legacy until 2.0 but eo api will become
> > the "supported stable and developed with new features" api. as you can mix
> > and match eo and legacy this works as you can access new features via eo.
> > but for efl 2 i think i'd like to see legacy gone as it necessitates also
> > lots of horrible internals and exposing to maintain that compatibility.
> > 
> > we can merge easily now as long as we install symlinks, OR we use "dummy
> > empty .so's that just have .so deps on others" . :) it would be abi and api
> > compatible. :)
> > 
> I'm not saying it can't be done now, just that the time of efl 2.0 would
> be a slightly more sane less confusing time to do it potentially. Are
> there many real benefits to doing it now rather then when the time for
> 2.0 comes around?

cedric has good reasons for merging eo and ecore at least right now because
promises which are a core eo concept rely on a loop to drive them as well as
handle cleanup etc. having these split across different build trees, .so's ext.
means making ugly "poking holes in the wall" hacks to make the 2 work together.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...