Yeah, time to break our svn again ! :-D On Tue, Dec 13, 2011 at 4:32 AM, Carsten Haitzler <ras...@rasterman.com> 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). > > this move won't happen immediately, so this is a warning to EVERYONE WITH > PENDING PATCHES AND SOURCE TREES DEPENDING ON OUR SVN HIERARCHY (e.g. people > with git clones of specific libraries)... your patches are about to get broken > badly and your git trees made ineffectual when it comes to merging in upstream > as we will totally redo our tree. > > 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. > > benefits: > > 1. massively reduced release workload.
That's a very good point. Doing bug fixes release already take much more time than it should ! > 2. massively better documentation as it now will be a single document for all > of efl nicely cross-referenced between each actual lib Just that argument is enough in my opinion to welcome the change ! > 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 Cleaning some option might be good, but most of them are really usefull in some scenario. So we should be careful on what we remove here. > 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. Oh ! And yes agreed ! -- Cedric BAIL ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
