On Tue, 13 Dec 2011 10:37:35 +0100 Cedric BAIL <cedric.b...@free.fr> said:
> 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. i'd kill them anyway on a new tree... as you can't do an amalgamated build of everything... unless we start making libefl.so's :) > > --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. then why not remove the allocator code? > > --enable-mempool-pass-through (always compile support) > > --enable-mempool-buddy (always compile support) > > Same for that one. then remove it entirely? either have it there always and able to be used and switched to at runtime by env vars or by code explicitly asking for it... or nuke it. if its code that never gets compiled and/or used.. its dead-weight :) > > --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. like? eina_log just dumps to stderr normally. something without stdout/stderr... is not a very useful system to us :) > > 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. well thats just for coverage... not for tests... (ie correctness tests) right? > > --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... yup. here's my take: so what? your build takes a few seconds more to build some binaries. live with it. that's a small price to pay in the scheme of the whole big blob of efl. :) > -- > 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
