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. > > 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. > >> >> 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. > >> >> > > >> >> > -- > >> >> > ------------- 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 > >> -- ------------- 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
