On Tue, 13 Dec 2011 14:02:00 +1000 David Seikel <[email protected]> said:
> 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? you'd have to choose components from the installed files. eg only include the libs/modules/headers you need. this may end up compiling more than you need - but so be it. > 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. it's happening... so the arguments against are just going to create noise. helping and going with the flow will be constructive. :) > > 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. now that's moot as its a single efl doc with everything cross-linked as its the one doxygen build. :) > > 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. no - it's going into the one efl blob. :) > -- > 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] ------------------------------------------------------------------------------ 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
