On Tue, Dec 13, 2011 at 10:29 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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)
If evas always need thread, indeed it doesn't make sense anymore to turn it on and off. > --enable-amalgamation (gcc can now do link time optimizations and frankly i > think many amalgamated builds are broken for efl anyway). Nah, they all work fine at the moment. I play with them every day. > --enable-mempool-chained-pool (always compile support) > --enable-mempool-fixed-bitmap (always compile support) We are not using it at all as far as i remember. > --enable-mempool-pass-through (always compile support) > --enable-mempool-buddy (always compile support) Same for that one. > --enable-mempool-one-big (always compile support) > --enable-voltron (hehehe yes - amusing... but we can add easter-eggs back in > later) :-D > --disable-log (no - we should always compile log capabilities) Some system don't come with a usable log infrastructure. > 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: Problem with test is that it require linking with gcov/lcov stuff, so every use of the library will always be tracked. Not very nice in my opinion. > --enable-e17 > --enable-tests > --enable-benchmark > --enable-build-examples > --enable-install-examples > > that's a lot that could go in eina already... :) As for example, yes, sounds usefull to at least always try to build them, it's an easy way to detect API break... -- 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
