On Tue, 13 Dec 2011 09:28:04 +0100 Cedric BAIL <cedric.b...@free.fr> said:
> 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. well here's some for eina i'd kill: --disable-posix-threads / --disable-win32-threads (require threads and simply choose either win32 threads or posix based on arch - evas is going to be requiring threads soon enough so it's time to bite the bullet). --enable-on-off-threads (always on) --enable-amalgamation (gcc can now do link time optimizations and frankly i think many amalgamated builds are broken for efl anyway). --enable-mempool-chaine--disable-logd-pool (always compile support) --enable-mempool-fixed-bitmap (always compile support) --enable-mempool-pass-through (always compile support) --enable-mempool-buddy (always compile support) --enable-mempool-one-big (always compile support) --enable-voltron (hehehe yes - amusing... but we can add easter-eggs back in later) --disable-log (no - we should always compile log capabilities) maybe a few others - like always compile benchmarks - maybe always compile tests - we possibly should simply have test binaries we can run that dont need any infra like "check". like: --enable-e17 --enable-tests --enable-benchmark --enable-build-examples --enable-install-examples that's a lot that could go in eina already... :) > > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
