On 24/09/16 10:07, marcel-hollerb...@t-online.de wrote: > On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote: >> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen <t...@osg.samsung.com> wrote: >>> On 22/09/16 00:34, Cedric BAIL wrote: >>>> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen <t...@osg.samsung.com> wrote: >>>>> On 19/09/16 23:33, Cedric BAIL wrote: >>>>>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen <t...@stosb.com> wrote: >>>>>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much >>>>>>> against it. >>>>>> >>>>>> There was a thread weeks ago. You indeed didn't take part of that >>>>>> discussion, but everyone else involved in that thread was ok. Actually >>>>>> the discussion evolved more into a what else to merge in. So their was >>>>>> an agreement before this email. >>>>> >>>>> Sorry, I missed that thread. What was the topic? >>>> >>>> Merging eo, efl and ecore. Like in the title :-) >>> >>> I remember that thread now, I misunderstood what you meant by merging >>> when you said it back then, and now with your promise inside lib/eo/ I >>> understand what you meant, and I'm very much against it. >>> >>> Let me clarify what I mean compared to my understanding of what you >>> mean. What I mean is what I thought was discussed in that thread. >>> I'm fine with: >>> Linking everything into one big fat ugly libefl.so (would rather not, >>> but OKish with that). >>> Having Efl.h that includes Eo.h, Elementary.h and etc. >>> Having an efl_init() and an efl_shutdown() that call them all. >> >> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just >> for reference. >> >>> But if you think about it, it's essentially what we have in elementary. >>> It does all of the above except for the one binary linked together. >>> Which I'm mostly OK with (although see Marcel's comment about eo_debug >>> about which I forgot. Modularity has many advantages). >>> >>> What I'm *not* OK with: >>> Creating interdependency between the libraries and essentially making >>> libefl.so Ecore 2.0. One place to store everything. Units make a lot of >>> sense, of the advantages have been discussed above. My eo_debug trick >>> (which is ready, I just need to enable it, again, see marcel's email for >>> details) requires this separation. >> >> Saw it, it's neat. Question, why limitting it to eo ? Would be quite >> useful to also turn on more debug in eina, no ? > > For the same reason as why there are different log domains, if i have a issue > with eo ref stuff, i would not like to get the complete output of ecore/eina. >
First of all, as Carsten said, we can solve it with domains, but also, as long as we don't create inter-dependency between ecore and Eo, that is keep Eo isolated even if in the same binary (which is what I care about), then we could just ld_preload a debug libeo.so that would only modify eo. -- Tom ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
