On Thu, 15 Oct 2015 12:30:11 +1000 David Seikel <[email protected]> said:
> On Thu, 15 Oct 2015 09:44:00 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > so to that effect in future we MUST merge libs. MUST merge modules. > > this does not mean we have to rename functions, but we need to build > > differently. my take for NOW is that we need to do this: > > > > lib... > > > > efl, eina, eo, emile, eet, ecore, eio > > -> efl > > > > ecore_input, ecore_input, ecore_audio, elocation, ecore_con, > > ecore_ipc, ecore_imf, efreet, efreet_trash, efreet_mime, eldbus, > > ecore_file -> efl_sys > > > > ecore_drm, ecore_x, ecore_fb, ecore_wayland, ecore_input_evas, > > ecore_imf_evas, ecore_evas, evas, edje, emotion, ector, ephysics > > -> efl_gfx > > > > ethumb_client > > -> stay for now (be replaced in future with a non-dbus file > > "preview" infra that doesn't require a central daemon - things like > > SMACK make ethumb pretty pointless, so move it more to a fork+execced > > child slave process to do the heavy lifting so permissions are > > inherited from the parent). > > > > eeze > > -> stay for now (be replaced with a high level device abstraction > > that doesn't look like or depend on linux sysfs at all) > > > > elementary > > -> stay > > As you know, I'm always harping on about squeezing EFL into tiny > embedded devices, and you specifically mention 32 MB systems. Your > response in the past to my concerns was along the lines of "compile > everything, leave out the .so files that are not needed". While it was > a barely acceptable solution to me, now you are planning on taking that > solution away. correct. the benefits are not worth the cost. reality is that 32mb systems work FINE with an efl with "everything there". the utility of the features and ability to DEPEND on the features being there in efl code without if ()'s or #ifdefs and fallbacks and "oh that only now half works because the feature was disabled" is worth the cost. > My previous embedded project used pre merged EFL, though that's mostly > coz the majority of my work was done before the EFL merge was started. > I'll be considering a new project soon, one that was planned when I > wrote the original, and based on the original. At the moment I can't > see that progressing to modern EFL, even though there's some new API > that might be useful, not to mention copious bug fixes. This proposed > change of yours would move EFL too far away from being useful for these > projects. actually that is a decision on your part to not accept "more". you would have to accept "more" if you built your project on chromium like some do, or qt, or a wide range of other toolkits. the way i see it, is it's better to be able to "guarantee that you can find an icon for X" than maybe have an api there or not (efreet). it is beetter to guarantee full intl input method support (ecore_imf) than maybe have it work, maybe not. we HAVE to have this for decent virtual keyboard input for touch screens. we have to have this for pretty much any language in east asia and having that all optional is not worth the cost. > Not to mention that having to compile all this excess crap means I have > to spend more time on making sure the build system for these projects > CAN compile all this extra crap. Not something the client wants me to > be spending time on, not something I want to be spending time on. It's > entirely useless makework that someone has to pay for. > > On the other hand, your arguments for combining libraries make perfect > sense. There needs to be a middle ground though. Especially for those > 32 MB systems, exactly the sort of system where it's very important to > cut out all the crap you don't need. So if the "just don't install > the .so files you don't need" method of cutting things down is going > away, we must implement a "give the builder options to not even bother > compiling the stuff you don't need". Which was discussed and rejected > before. Rejecting that sounded like a bad idea to me at the time, > sounds like an even worse idea now. In the end, would have been less > work if we had done it my way the first time. :-P stuff that isn't used is not PAGED IN. :) > So please, let's consider those 32 MB systems when we make these plans > to reduce options for reducing the footprint. Coz in the end, it wont > be reducing the footprint if all this extra unneeded crap has to come > along for the ride. Just makes things harder for tiny system > developers, which might just make us choose something else. I'm too > heavily invested in EFL across a few projects, I really really really > don't want to be forced to choose something else. 32M RAM is what i am speaking of. if something isn't used it shouldn't get paged in (as long as the code for that is localized and not scattered about). give me a list of dependencies you don't want. > P.S. My other major EFL project (virtual world client / server) is > using modern EFL, it's using EO and 3D, so I'm hoping that EO stability > does come soonish, I'm getting tired of having to fix this project each > time there's a new EFL release. Same applies to Evas_3D, but that's not > part of this thread. Yes, I'm also constantly harping on about not > using bleeding edge stuff, but in this case the project itself isn't > expected to be useful to anyone until well after EO and Evas_3D are > stable. It's a huge project. Bleeding edge makes sense at this stage > of this project, I'm not expecting any one else to even try to compile > it yet. > > Even this project would suffer from this "compile everything dammit, > distribute everything dammit" attitude. Like I said, it's a huge > project, making the job of people trying to build it even harder by > adding dependencies that are never used is just asking for trouble. > It's open source, it's huge, I could do with other developers, I don't > want to make it any harder for them to come on board. Especially not > "build all of this extra useless crap, plus dependencies" harder. I > had enough of that trying to build ewe, an enormous rabbit hole of > dependencies on dependencies on dependencies, that I eventually gave up > on, it just wasn't worth the effort. I'll need a different web browser > solution for this project. Virtual world systems need embedded web > browsers, for putting web pages on 3D objects in world. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
