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. 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. 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 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. 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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
