On Tuesday, December 13, 2011, Carsten Haitzler <[email protected]> wrote: > On Tue, 13 Dec 2011 08:16:08 -0200 Gustavo Sverzut Barbieri > <[email protected]> said: > >> > 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? > > yes. i have used it for real. that's why i want it. i want us to actually use > it - for people submitting patches from wherever and even internally for > new/junior developers. i like it because you can review in-line and everyone > can see the review comments - a bit more wiki-like than in email.
Do you see it being used constantly? Given our poor trac usage? I see it working, for instance for webkit all patches must come from bugs, then they merged patch review in bugzilla with nice webui, then they use a commit bot that scans for approved patches. This is with svn, if you want it then why not borrow their infra and try it right now? I'm pretty sure I have hard time remembering to use these tools. So either make it mandatory without patches or review at Edevel, or have gerrit to forward review here. >> > 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 ;-) > > heheheh > >> > 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 ;-) > > so the 1 liner to test that u have a working dist tarball and make it for > you... i am not giving that feature up without a fight :) but i'm serious. if > you want cmake used.. you're going to have to put it through the wringer of > fear and doubt and will have to at least show us that these features are a > "simple 3 liner in cmakelists.txt" or whatever, but i'd be immensely pissed off > at not baing able to make and test and dist tarball anymore. this needs a > solution. i'd call a veto on cmake until this is solved. :) if there is a nice > neat solution and it just doesn't happen to be a default feature - fine. > >> 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. > > well if we never switch - it won't be of much use having 2 build systems. one > will always break (the one people who do the code don't use). :) > >> 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 > > well i saw your other mail - ok, but solve the distcheck thing... and then > lets see. i don't want to move to it during a "efl tree merge" so any merge > would simply be merging the autofoo stuff. i do know that cmake is massively > faster in init and it does have a nice color hilighted build with a percentage > meter etc. - nice. > > but it is, around here, new, untested, untrusted and unknown. there WILL need > to be a quick README-cmake.txt of some sort letting us know how to do things > like: > > ./configure --enable-X > ./configure --disable-X > ./configure --with=X=X > etc. (other options how to enable/disbale/set things etc.) > make clean distclean > make clean maintainer-clean > make dist > make distcheck > make DESTDIR=/path/to/whatever install > > maybe a few other common things > > you're going to have to convince the skeptics that this is good and provide an > easy path. :) but if you can do it... let's talk further. Fair enough, now we are talking. I'll wait you to merge it with Autofoo then I will try to have a cmake build for it with the same options and the readme-cmake.txt >> >> >> 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 < [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. >> >> >> > 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. >> >> ------------------------------------------------------------------------------ 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
