On Tuesday, December 13, 2011, Carsten Haitzler <[email protected]> wrote: > On Tue, 13 Dec 2011 10:37:35 +0100 Cedric BAIL <[email protected]> said: > >> On Tue, Dec 13, 2011 at 10:29 AM, Carsten Haitzler <[email protected]> >> wrote: >> > On Tue, 13 Dec 2011 09:28:04 +0100 Cedric BAIL <[email protected]> said: >> >> Yeah, time to break our svn again ! :-D >> >> >> >> On Tue, Dec 13, 2011 at 4: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. >> >> > >> >> > 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.acand >> >> > 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 wori'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 :)
For libefl it's better to link all lib$X.a into a single so. In that sense the amalgamation is doable. Btw gentoo users test amalgamation every time, as it's mandated by ebuild :-) >> > --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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > ------------- 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
