On Tuesday, December 13, 2011, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 13 Dec 2011 07:51:52 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> On Tuesday, December 13, 2011, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Tue, 13 Dec 2011 07:13:45 -0200 Gustavo Sverzut Barbieri >> > <barbi...@profusion.mobi> said: >> > >> >> +1 >> >> >> >> Could we also move to cmake? How about git? I can have people to help >> with >> > >> > cmake -> no. despite how much i may hate autofoo... it's here and works >> and is >> > a devil we and many know. git - not currently, later on after e17 and >> > elementary are out. i have a list of requirements for it to come it - like >> > gerrit integration is a big fat must. we must have "git-commits" list >> working, >> > have a bot monitoring e-devel for git patch emails that will push them to >> > gerrit for review if they come in. it must be integrated to trac, and >> frankly >> > our rev no stuff we have now is based on svn commit # and will break - so >> first >> > i think a merge into a single efl tree lets us have a single point to >> chznge/fix >> > this. >> >> Funny to see this gerrit et al here, it's a trending topic at profusion as >> well and many projects. I'm saying this forever, the tool (or lack of it) >> is not the problem if the developers are unchanged. I'm all for nice tools, >> but I doubt gerrit is of any help here. >> >> Our volume of patches is very low and unlike to change. Our usage of tools >> is very low and unlike to change (read trac). Keeping the reviews at Edevel >> is the best way at the moment, and it does scale nicely, check LKML for a >> proof of that. >> >> But the funny part is that it's a requirement to move to have tools we >> don't have now. There will also be changes to the workflow that are enough >> to justify the change... No need to block due tools :-( > > i want gerrit. if we are using git then gerrit is a must. i want it. our > existing managament infra has to work via git too - that means for example our > devs dir management. website - on commit updates automatically. all the other > things we have running need to work (doc generation etc.). do this after e17 > and elm are done.
To avoid endless discussion have you ever tried it for real? What do you want from it? >> > so first lets clean house before we do more releases - so releases CAN >> happen >> > much more easily. right now they only get harder and more work each time >> as >> > more libs get added. >> >> Sad but expected from you. If we have cmake in parallel and it works, what >> are the chances we get it as the official? > > not touching cmake. even your friend - lennart, advises against it. you aren't > going to quote him? :) He is brain dead regarding this concept. I've told him already ;-) > seriously - cmake does introduce: > > the devil we don't know. i sure don't know it. i'd say most devs here don't. > totally new build system and now we can't make the move easy by re-using make > Makefile.am's and configure.ac/m4 snippets. this will just make things worse. > as cedric said - cross-compile issues with cmake, less portability, unknown > usability for win32/wince support, and a bigger barrier of entry. so explain to > me what the use of cmake is good for if it now has more build issues than > autofoo? let's not go change build systems that have done things like given us > 1 line distchecks for years and handled cross-compiling, destdir for packaging > and more for a long time. Lack of builtin distcheck is manageable, much more than our dozen m4 files to manage modules ;-) Really, we can help here, you personally don't need to bother. After its ready it's super simple to change! You won't have problems, don't be afraid, we can help you if you have issues. Also this can come as parallel build, but I'm just investing my company time if we have any chance to get accepted as the default >> >> 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 <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. >> >> > 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.acand >> >> 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) 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 >> ------------------------------------------------------------------------------ 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
