+1 Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well.
Thanks for taking this long due change! On Tuesday, December 13, 2011, 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. > > 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 > ------------------------------------------------------------------------------ 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
