On Tue, 13 Dec 2011 12:32:00 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> ok - this 10 gazillion separate libraries is just not managable. we > are going to make a single build and source tree for efl. that means > core efl. that means 1 configure script for all. 1 base makefile > tree. something like: > > efl > efl/src > efl/src/evas/... > efl/src/eina/... > efl/src/edje/... > ... > > we will still produce multiple shared libs, but under 1 build tree. 1 > source tarball for it all. 1 configure script. 1 efl version. 1 doc > tree. this will cover core efl. right now that means: > > eina eet evas ecore embryo edje eeze efreet e_dbus > evas_generic_loaders (evil - only compiled if on win32/ce) > > later elementary will get added (eio, emotion too). Will this mean that, for example my embedded project that only uses eina eet evas ecore embryo edje, will have to get a lot bigger? Or can I easily choose the components I build and install, even if I have to put up with a bigger source tarball? So long as I still get to easily cut out the stuff my embedded project does not require, like IMF and X support. Though I don't see where eeze, efreet, e_dbus, eio, emotion, or elementary would fit into my upcoming big desktop app either. Well, maybe emotion. > some people will not like this. sorry. reality is that world is > totally confused by EFL. we spend immense effort trying to educate > the world where all it sees is "efl" not "evas + edje + ecore +...". > the fact is we do releases as if it were a single efl. we may as well > start doing it that way. This I agree with. I can see lots of arguments coming though. > benefits: > > 1. massively reduced release workload. Great. > 2. massively better documentation as it now will be a single document > for all of efl nicely cross-referenced between each actual lib Good, I had a problem in documenting the edje lua stuff, a lot of it needed to reference evas and other libraries. My doxygen skills are limited, was not sure how to do that. > 3. guaranteed synchronized release so we don't have to fine-tune > check the "required versions of efl libs" > 4. an actual release that resembles what the world thinks of us. > 5. doesn't break any api or abi compatibility > 6. a chance to start again with a simple single clean configure.ac > and remove many of the myriad of options in efl that just cause > problems and have little value All good things. > 7. makes much more sense to have a single tree when using something > like git as we either would have a single cit repo that just copies > svn (possible but not really using git properly) or we split into > things like 1 git for e17, one for core efl, one for "misc" etc. and > so merging into a single efl tree makes sense if we ever move to > using git. Personally I think it should still be split a little further. eina eet evas ecore embryo edje is good for embedded work that a frame buffer is a good match for. Not everything needs X or desktop stuff. The rest could be "X desktop" and "toolkit". You could use elementary without needing anything other than eina eet evas ecore embryo edje for instance. Efreet and e_dbus I would put into "misc". Not so sure about eeze and eio, I'm not actually familar with them. You'll get lots of people arguing the split though. -- 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
------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
