On Tue, Dec 13, 2011 at 1:32 AM, Carsten Haitzler <[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). > > 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. > Not trying to derail the thread into something related to the original topic, but is there a tentative date for such change? How will it be done? Best regards, Luis Felipe > > 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. > 2. massively better documentation as it now will be a single document for > all > of efl nicely cross-referenced between each actual lib > 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 > 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. > > -- > ------------- 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 > -- Luís Felipe Strano Moraes http://www.strano.org ------------------------------------------------------------------------------ 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
