Re: [E-devel] new build tree for efl.
Hi all, A bit late to the party, I've been (and still am) very busy lately! What a nice surprise! Carsten, that's a very good idea, I agree and support the move to a single tree! Actually, what do you think about having one tree for core libs and one for toolkits like glib and gtk having separate trees? Just an idea, a would still personally prefer a single tree. For the other subjects thrown in this thread, I'm very happy to hear about the possible move to git, it's really great! And yes, I definitely agree that the move shouldn't happen until after the release.. there's no reason to do it right now, and it would just slow down the release at this point. So I think single tree move should be done asap, but the git move only after the release. As for the cmake debate.. I don't like cmake, honestly.. I've had to deal with it a couple of times and it was hell.. I ended up knowing how to use it (not how to create/modify it) and it is ok.. it just feels so weird and alien from the usual autofoo stuff that I don't feel at ease using it. However, seeing Gustavo's arguments, I tend to agree that it is probably preferable and it does have many good advantages. As for cross-compilation, it actually works great, you just need to give it the argument -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/file and it will just cross-compile it.. I have made (with difficulty) a cmake toolchain file for the ps3, and I just give that as argument and it seems to work and properly create the libs I need with cmake, so it does make things simpler.. and I do like how fast it configures itself and the progress bar, etc... Yes, autofoo is bad, but we all know it and love it.. but yes, modifying configure.ac and makefile.am can be a huge pain. I would like to see the efl have cmake for testing purposes only (post single-tree with autofoo) before a decision is made. One thing I remember seeing in a project was autoffo around cmake.. so basically the ./configure would mkdir build and run the cmake command in it, and the Makefile would just run make in the build dir. This allowed people not used to cmake to just ./configure make normally and get the expected result without wondering how it should be done. I believe that if there is a move to cmake, that this kind of thing would be necessary. For the distcheck, I don't really know what to say, it's a very good point and I'm actually surprised that cmake doesn't support something like that. Implementing it with makefile.am could be a solution.. but the cost of maintaining both cmake and makefile files would be too high. Gustavo, find a solution for that if you want cmake to even be considered! (I think Carsten already made that clear) :) Anyways, good stuff, keep it up! I'm glad to see this happening! KaKaRoTo On Wed, Dec 14, 2011 at 8:04 PM, David Seikel onef...@gmail.com wrote: On Wed, 14 Dec 2011 13:40:16 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/14 Cedric BAIL cedric.b...@free.fr: No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called git. :-) It's time for all of you to see the light. These build systems you like to praise so much are but the work of the Devil. They are tools to make you lazy and accustomed to go the easy way with things. Before you know it, you will find yourself selling your own souls to avoid a few more keystrokes. The only true path is to manually call the right compiler and linker lines on each file of the project I actually did that with my embedded project. Figured I did not really need pkgconfig and it's circular dependency on glib. The actual app itself is so easy to compile that a small shell script does it. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___
Re: [E-devel] new build tree for efl.
On Sat, 17 Dec 2011 05:14:21 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: progress bar, etc... Yes, autofoo is bad, but we all know it and love it.. I suspect a lot of us hate it, I do. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Sat, 17 Dec 2011 05:14:21 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Hi all, A bit late to the party, I've been (and still am) very busy lately! What a nice surprise! Carsten, that's a very good idea, I agree and support the move to a single tree! Actually, what do you think about having one tree for core libs and one for toolkits like glib and gtk having separate trees? Just an idea, a would still personally prefer a single tree. well i'm thinking of just ensuring we minimize release work for core efl. for added bonuses that are not important when it comes to doing regular releases, they can live in their own trees unless they become important/core. :) For the other subjects thrown in this thread, I'm very happy to hear about the possible move to git, it's really great! And yes, I definitely agree that the move shouldn't happen until after the release.. there's no reason to do it right now, and it would just slow down the release at this point. So I think single tree move should be done asap, but the git move only after the release. this has always been my position. we're not changing scm's until efl 1.0 and e17 are out (efl 1.0 is - e17 isn't, elementary is now added too) :) As for the cmake debate.. I don't like cmake, honestly.. I've had to deal with it a couple of times and it was hell.. I ended up knowing how to use it (not how to create/modify it) and it is ok.. it just feels so weird and alien from the usual autofoo stuff that I don't feel at ease using it. However, seeing Gustavo's arguments, I tend to agree that it is probably preferable and it does have many good advantages. As for cross-compilation, it actually works great, you just need to give it the argument -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/file and it will just cross-compile it.. I have made (with difficulty) a cmake toolchain file for the ps3, and I just give that as argument and it seems to work and properly create the libs I need with cmake, so it does make things simpler.. and I do like how fast it configures itself and the progress bar, etc... Yes, autofoo is bad, but we all know it and love it.. but yes, modifying configure.ac and makefile.am can be a huge pain. i'd say we all know and hate autofoo... but yes - we do know it. and it is the devil we know, with all its warts. it has served us for many years and any change to cmake would be rather drastic. let's get elm and e17 out and then look at cleaning up our tree so future releases are not something that seems a daunting task and so on.. then things can roll more smoothly. as such we actually have done releases over the past year, and so we will continue to. i don';t agree with there being some headlong rush into releasing incredibly rapidly as in the end quality will suffer. i believe we'll get releases out as time goes on and make things better. i just don't want to see some all-out-rush :) I would like to see the efl have cmake for testing purposes only (post single-tree with autofoo) before a decision is made. One thing I remember seeing in a project was autoffo around cmake.. so basically the ./configure would mkdir build and run the cmake command in it, and the Makefile would just run make in the build dir. This allowed people not used to cmake to just ./configure make normally and get the expected result without wondering how it should be done. I believe that if there is a move to cmake, that this kind of thing would be necessary. For the distcheck, I don't really know what to say, it's a very good point and I'm actually surprised that cmake doesn't support something like that. Implementing it with makefile.am could be a solution.. but the cost of maintaining both cmake and makefile files would be too high. Gustavo, find a solution for that if you want cmake to even be considered! (I think Carsten already made that clear) :) i think other than as a test/demo, maintaining both cmake and autofoo build setups is going to ultimately be a waste of time as one of them will keep breaking (likely cmake) and then be removed. as a short transition period it's probably ok - but we need to be prepared to cancel the transition, if it doesn't turn out well. i'm not even saying there WILL be a transition yet. i'm simply right now willing to talk about cmake further and see if some distcheck solution appears. if it does - talk a bit more seriously. :) Anyways, good stuff, keep it up! I'm glad to see this happening! KaKaRoTo On Wed, Dec 14, 2011 at 8:04 PM, David Seikel onef...@gmail.com wrote: On Wed, 14 Dec 2011 13:40:16 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/14 Cedric BAIL cedric.b...@free.fr: No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called
Re: [E-devel] new build tree for efl.
On 12/13/2011 04:31 PM, Vincent Torri wrote: On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torrivincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torrivincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. We'll stay and help, it's not a drop and run thing. Don't worry. And as for learning the language. I do know, both actually. Some of the helper m4 files were written by me, like the optional plugin used by e17. I can guarantee you, I just came to like cmake after I tried it. And even being autofoo person since 1998 I find my way easier on cmake than autofoo. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. Yes, for the current solution. But is that the final solution? Wouldn't it be better to integrate more natively with win32 apis if there was manpower to help fix the VS bugs? fixing bugs ? well, it's mainly about asm : the syntax is different (intel vs ATT). If you want to support both syntaxes and yes, there's also some of the c99 features used in the efl and not supported by vc++. Feel free to fix them. I prefer cross compiling, nowadays again, it's a matter of learning a langage. compare adding an option at autoconf and cmake: cmake: OPTION(NAME Some documentation for help INIT_VAL) autoconf: AC_ARG_ENABLE(NAME, AC_HELP_STRING([--enable-NAME], [Some documentation for help @:@default=detect@:@]), [NAME=$enableval], [NAME=INIT_VAL] ) seems very close, right? but if someone drops [] it will work, except in some cases that requires quotes, etc. It's tricky. I forgot to say : is there a --help option with cmake ? unfortunately cmake --help is not equivalent to configure --help. Moreover I find the cmake syntax for the options a bit annoying. For the rest, well I am not using cmake often enough to really have constructive criticism but I would stick to autofoo tools since everything is already written and working. Mathieu -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
Wow, this is interesting poll. I marked both git and svn because I use both for real. I accept any tools that are working well. But from my experience, git is superior to svn and really helpful to developer. So I prefer git :) Daniel Juyung Seo (SeoZ) On Wed, Dec 14, 2011 at 3:09 AM, Leif Middelschulte leif.middelschu...@gmail.com wrote: 2011/12/13 Cedric BAIL cedric.b...@free.fr: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 You are getting to much social :-) Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. Thanks for taking this long due change! First about git. Today tool provided to do review and managing branch are just amazing. I am thinking about gerrit, but also github and gittorrious. So if we switch to git, we need to have this kind of tool so it will be usefull. I see it will be also much more easy to do backport. So I am now on the side that if we describe properly how to contribute after switching to git, the tool are now great and it's worth doing the switch. I would just postpone it until we do release e17, elm, eio, ethumb and emotion. Many people will be happy ;-) http://doodle.com/h9dgtwbhhtv5c9sw - Finally, I can delete that poll. About cmake, I don't know its current status, but in the past I did suffer from its lack of portability and limitation to do cross compilation. Before any switch to it, I want to be sure that all this issue are solved. That we will be able to provide a working build on all our target system and that we can easily do all cross compilation. -- 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 -- Leif -- 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 -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Wed, Dec 14, 2011 at 4:26 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Wow, this is interesting poll. I marked both git and svn because I use both for real. I accept any tools that are working well. But from my experience, git is superior to svn and really helpful to developer. So I prefer git :) No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called git. :-) -- Cedric BAIL -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
2011/12/14 Cedric BAIL cedric.b...@free.fr: No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called git. :-) It's time for all of you to see the light. These build systems you like to praise so much are but the work of the Devil. They are tools to make you lazy and accustomed to go the easy way with things. Before you know it, you will find yourself selling your own souls to avoid a few more keystrokes. The only true path is to manually call the right compiler and linker lines on each file of the project, and don't forget to express each parameter in its full form. Don't fall to the temptation of alias and environment variables. -- Cedric BAIL -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On 12/14/2011 04:33 PM, Cedric BAIL wrote: On Wed, Dec 14, 2011 at 4:26 PM, Daniel Juyung Seoseojuyu...@gmail.com wrote: Wow, this is interesting poll. I marked both git and svn because I use both for real. I accept any tools that are working well. But from my experience, git is superior to svn and really helpful to developer. So I prefer git :) No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... a troll about cmake. No we would not do that. Every one, back to cmake troll ! Please forget about this minor things called git. :-) Oh you bad french man ;-). git is not a minor thing, but curiously I also like it so +1 for git :-). it is easier to use when the servers change addresses for instance, or if you want to reset things to an established state (git --reset hard is the magic command). Mathieu -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Thu, Dec 15, 2011 at 12:33 AM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Dec 14, 2011 at 4:26 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Wow, this is interesting poll. I marked both git and svn because I use both for real. I accept any tools that are working well. But from my experience, git is superior to svn and really helpful to developer. So I prefer git :) No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... haha are you happy with that? I'm just reading through all emails for this thread and just replied what looked interesting. Every one, back to cmake troll ! Please forget about this minor things called git. :-) yeah keep rock and roll! -- Cedric BAIL -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Wed, Dec 14, 2011 at 3:09 AM, Leif Middelschulte leif.middelschu...@gmail.com wrote: 2011/12/13 Cedric BAIL cedric.b...@free.fr: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 You are getting to much social :-) Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. Thanks for taking this long due change! First about git. Today tool provided to do review and managing branch are just amazing. I am thinking about gerrit, but also github and gittorrious. So if we switch to git, we need to have this kind of tool so it will be usefull. I see it will be also much more easy to do backport. So I am now on the side that if we describe properly how to contribute after switching to git, the tool are now great and it's worth doing the switch. I would just postpone it until we do release e17, elm, eio, ethumb and emotion. Many people will be happy ;-) http://doodle.com/h9dgtwbhhtv5c9sw - Finally, I can delete that poll. no!!! this is really interesting to me :) don't delete that poll. just leave it :) Daniel Juyung Seo (SeoZ) About cmake, I don't know its current status, but in the past I did suffer from its lack of portability and limitation to do cross compilation. Before any switch to it, I want to be sure that all this issue are solved. That we will be able to provide a working build on all our target system and that we can easily do all cross compilation. -- 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 -- Leif -- 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 -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Wed, 14 Dec 2011 16:43:00 +0100 Mathieu Taillefumier mathieu.taillefum...@free.fr said: On 12/14/2011 04:33 PM, Cedric BAIL wrote: On Wed, Dec 14, 2011 at 4:26 PM, Daniel Juyung Seoseojuyu...@gmail.com wrote: Wow, this is interesting poll. I marked both git and svn because I use both for real. I accept any tools that are working well. But from my experience, git is superior to svn and really helpful to developer. So I prefer git :) No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... a troll about cmake. No we would not do that. Every one, back to cmake troll ! Please forget about this minor things called git. :-) Oh you bad french man ;-). git is not a minor thing, but curiously I also like it so +1 for git :-). it is easier to use when the servers change addresses for instance, or if you want to reset things to an established state (git --reset hard is the magic command). i wonder where anyone got the idea that this is a vote or a poll? :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
On Wed, 14 Dec 2011 13:40:16 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/14 Cedric BAIL cedric.b...@free.fr: No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called git. :-) It's time for all of you to see the light. These build systems you like to praise so much are but the work of the Devil. They are tools to make you lazy and accustomed to go the easy way with things. Before you know it, you will find yourself selling your own souls to avoid a few more keystrokes. The only true path is to manually call the right compiler and linker lines on each file of the project I actually did that with my embedded project. Figured I did not really need pkgconfig and it's circular dependency on glib. The actual app itself is so easy to compile that a small shell script does it. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
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. 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. Oh ! And yes agreed ! -- 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
Re: [E-devel] new build tree for efl.
+1 Could we also move to cmake? How about git? I can have people to help with 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.ac and 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 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 -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 09:38:38 +0100 Guillaume Friloux guillaume.fril...@asp64.com said: On 13/12/2011 06:43, Carsten Haitzler (The Rasterman) wrote: On Tue, 13 Dec 2011 14:02:00 +1000 David Seikel onef...@gmail.com said: Will this mean that, for example my embedded project that only uses eina eet evas ecore embryo edje, will have to get a lot bigger? Or can I easily choose the components I build and install, even if I have to put up with a bigger source tarball? you'd have to choose components from the installed files. eg only include the libs/modules/headers you need. this may end up compiling more than you need - but so be it. Hello raster, my english is not that good, and i need clear statements. Here i use eina and ecore on servers and i am looking to add eio/e_dbus. Are you saying that i also will have to add evas→e and maybe even →elementary on my servers ? you will have to install to a destdir and then only package.use the bits you want from the install. we could make compiling of components optional and things like x support optional - it still will be, but i want to remove as many options as possible. -- - 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
Re: [E-devel] new build tree for efl.
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) --enable-amalgamation (gcc can now do link time optimizations and frankly i think many amalgamated builds are broken for efl anyway). --enable-mempool-chaine--disable-logd-pool (always compile support) --enable-mempool-fixed-bitmap (always compile support) --enable-mempool-pass-through (always compile support) --enable-mempool-buddy (always compile support) --enable-mempool-one-big (always compile support) --enable-voltron (hehehe yes - amusing... but we can add easter-eggs back in later) --disable-log (no - we should always compile log capabilities) 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: --enable-e17 --enable-tests --enable-benchmark --enable-build-examples --enable-install-examples that's a lot that could go in eina already... :) 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. Oh ! And yes agreed ! -- 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.
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 07:13:45 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. I could help with cmake as well. Personally I'd prefer git over svn, and cmake over autofoo. But then again, I'd prefer almost anything over autofoo. lol On the other hand, I've not tried all the alternatives. Git and cmake are not perfect. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 You are getting to much social :-) Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. Thanks for taking this long due change! First about git. Today tool provided to do review and managing branch are just amazing. I am thinking about gerrit, but also github and gittorrious. So if we switch to git, we need to have this kind of tool so it will be usefull. I see it will be also much more easy to do backport. So I am now on the side that if we describe properly how to contribute after switching to git, the tool are now great and it's worth doing the switch. I would just postpone it until we do release e17, elm, eio, ethumb and emotion. About cmake, I don't know its current status, but in the past I did suffer from its lack of portability and limitation to do cross compilation. Before any switch to it, I want to be sure that all this issue are solved. That we will be able to provide a working build on all our target system and that we can easily do all cross compilation. -- 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
Re: [E-devel] new build tree for efl.
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. --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. --enable-mempool-pass-through (always compile support) --enable-mempool-buddy (always compile support) Same for that one. --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. 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. --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... -- 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
Re: [E-devel] new build tree for efl.
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. 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. 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.ac and 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 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 -- 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
Re: [E-devel] new build tree for efl.
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
Re: [E-devel] new build tree for efl.
On 13/12/11 11:13, Gustavo Sverzut Barbieri wrote: +1 Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. As raster said, autofoo is a beast we all know and can handle. I'm not very much against cmake as I just don't know it well enough. As for git, like raster said, lets wait after e17 out, and as the main git-troll, I obviously support it very much. As for this change: this is a much needed change, but for the sake of keeping history of everything, lets wait until we move to git which iirc will allow us to keep the whole history. -- Tom. -- 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Carsten Haitzler ras...@rasterman.com wrote: 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.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?
Re: [E-devel] new build tree for efl.
On 13/12/11 11:51, Gustavo Sverzut Barbieri wrote: If we have cmake in parallel and it works, what are the chances we get it as the official? I think you first need to prove people why we want to move. What are the advantages? disadvantages? Why would we care? and etc... Then, after convincing everyone, it should be a lot easier. -- Tom. -- 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
Re: [E-devel] new build tree for efl.
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. 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? :) 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. 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 07:55:47 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: For libefl it's better to link all lib$X.a into a single so. In that sense the amalgamation is doable. well with a single build tree.. we could potentially produce a single libefl.so and just make compatibility symlinks to libevas.so, libeina.so etc... :) it'd actually work... somehow :) i suspect it may even improve our startup times. :) 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 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 -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 11:54:29 +0200 Tom Hacohen tom.haco...@partner.samsung.com said: On 13/12/11 11:13, Gustavo Sverzut Barbieri wrote: +1 Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. As raster said, autofoo is a beast we all know and can handle. I'm not very much against cmake as I just don't know it well enough. As for git, like raster said, lets wait after e17 out, and as the main git-troll, I obviously support it very much. As for this change: this is a much needed change, but for the sake of keeping history of everything, lets wait until we move to git which iirc will allow us to keep the whole history. then that's a bit of a problem - we'd have to do at least another release of evas as elm requires evas-gl which is only in trunk... -- - 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Tom Hacohen tom.haco...@partner.samsung.com wrote: On 13/12/11 11:51, Gustavo Sverzut Barbieri wrote: If we have cmake in parallel and it works, what are the chances we get it as the official? I think you first need to prove people why we want to move. What are the advantages? disadvantages? Why would we care? and etc... Then, after convincing everyone, it should be a lot easier. Cmake is a single simple language that generates native build infra. That alone justifies the change. Autofoo is m4 that I know, but very few people know about. Then there is shell, make and automate extensions. Cmake is very simple and flexible, using it with webkit was a hard enough test. It is very big (bigger than libefl will be), it's full of toggles and options, nowadays it's shared by multiple ports (blackberry's rim, clutter and EFL). I'm working with Autofoo with 10+ years and I was somehow new to webkit and completely new to cmake, I wrote the biggest part of build in 1 day, with help we managed to finish it in less than one week. It will also generate visual studio and Xcode to help other systems, will optionally present config options in nice user interfaces (ncurses or qt), will show percentage on builds, etc. it's is less stupid wrt basic tests, then it configures immediately and not takes minutes like autogen/configure And it does fine for cross compile, as being show by qt/kde people, webkit and others. Is that enough? -- 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
Re: [E-devel] new build tree for efl.
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
Re: [E-devel] new build tree for efl.
On 13/12/11 12:09, Gustavo Sverzut Barbieri wrote: Cmake is a single simple language that generates native build infra. That alone justifies the change. Autofoo is m4 that I know, but very few people know about. Then there is shell, make and automate extensions. Cmake is very simple and flexible, using it with webkit was a hard enough test. It is very big (bigger than libefl will be), it's full of toggles and options, nowadays it's shared by multiple ports (blackberry's rim, clutter and EFL). I'm working with Autofoo with 10+ years and I was somehow new to webkit and completely new to cmake, I wrote the biggest part of build in 1 day, with help we managed to finish it in less than one week. It will also generate visual studio and Xcode to help other systems, will optionally present config options in nice user interfaces (ncurses or qt), will show percentage on builds, etc. it's is less stupid wrt basic tests, then it configures immediately and not takes minutes like autogen/configure And it does fine for cross compile, as being show by qt/kde people, webkit and others. Is that enough? You failed to mention the downsides, but as for advertising CMake, yeah, that's more than enough. What I was trying to say, is that although I very much respect your opinions, tech-decisions, and recommendation (non Apple related at least, damn fan-boy), you can't expect me, or others to just hop on the CMake boat without being really convinced. :) I believe you it's better, but it still needs to be proved. I guess that adding CMake support, or at least proving all we want can be done is the first step. -- Tom. -- 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Tom Hacohen tom.haco...@partner.samsung.com wrote: On 13/12/11 12:09, Gustavo Sverzut Barbieri wrote: Cmake is a single simple language that generates native build infra. That alone justifies the change. Autofoo is m4 that I know, but very few people know about. Then there is shell, make and automate extensions. Cmake is very simple and flexible, using it with webkit was a hard enough test. It is very big (bigger than libefl will be), it's full of toggles and options, nowadays it's shared by multiple ports (blackberry's rim, clutter and EFL). I'm working with Autofoo with 10+ years and I was somehow new to webkit and completely new to cmake, I wrote the biggest part of build in 1 day, with help we managed to finish it in less than one week. It will also generate visual studio and Xcode to help other systems, will optionally present config options in nice user interfaces (ncurses or qt), will show percentage on builds, etc. it's is less stupid wrt basic tests, then it configures immediately and not takes minutes like autogen/configure And it does fine for cross compile, as being show by qt/kde people, webkit and others. Is that enough? You failed to mention the downsides, but as for advertising CMake, yeah, that's more than enough. What I was trying to say, is that although I very much respect your opinions, tech-decisions, and recommendation (non Apple related at least, damn fan-boy), you can't expect me, or others to just hop on the CMake boat without being really convinced. :) I believe you it's better, but it still needs to be proved. I guess that adding CMake support, or at least proving all we want can be done is the first step. Biggest drawbacks are: - being new and requiring people to change - lack of builtin distcheck For distcheck there is cpack + ctest, but it need some tweaking. -- 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
Re: [E-devel] new build tree for efl.
My vote is for git + gerrit. I find it to be convenient over email reviews, in that, I can see the complete code and get the context, rather than read the diff (+/-) format and then look up the code. I am a bit biased here because I am used to gerrit. For someone new to EFL, I believe gerrit is a big plus. I have been using both automake and cmake on Linux. Not many problems with either of them so far. I will follow the crowd on this one :) --- Original Message --- Sender : Carsten Haitzlerras...@rasterman.com Date : Dec 13, 2011 19:02 (GMT+09:00) Title : Re: [E-devel] new build tree for efl. 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. 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? :) 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. 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
Re: [E-devel] new build tree for efl.
On 13/12/11 12:27, Gustavo Sverzut Barbieri wrote: Biggest drawbacks are: - being new and requiring people to change - lack of builtin distcheck For distcheck there is cpack + ctest, but it need some tweaking. Cool. Important thing I forgot to mention: I support the switch to CMake, I just don't find it as important as the move to git. Get it working with EFL on the current supported platforms and you will have me lobbying for you. -- Tom. -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 08:16:08 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi 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 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 10:29:50 + (GMT) SANJEEV BA as290...@samsung.com said: My vote is for git + gerrit. I find it to be convenient over email reviews, in that, I can see the complete code and get the context, rather than read the diff (+/-) format and then look up the code. I am a bit biased here because I am used to gerrit. For someone new to EFL, I believe gerrit is a big plus. well after a decade of reading unified diff's (the +/- things)... you get good at it :)... but gerrits commenting inline in the changes is nice - and everyone being able to look and see the comments and add more of their own in places would help us do group reviews better. I have been using both automake and cmake on Linux. Not many problems with either of them so far. I will follow the crowd on this one :) --- Original Message --- Sender : Carsten Haitzlerras...@rasterman.com Date : Dec 13, 2011 19:02 (GMT+09:00) Title : Re: [E-devel] new build tree for efl. 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. 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? :) 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. 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:16:08 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi 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 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 08:43:00 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Tuesday, December 13, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:16:08 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi 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? yes. 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? gerrit is immediate inline-commenting. trac isn't :) 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. you don't have to remember. gerrit emails you asking for a review :) 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 that's reasonable... just remember... the only way you're taking make distcheck from me is by prying it out of my cold dead fingers! make distcheck will keep autofoo alive and its going away over my dead cold stinking body unlesss cmake has an equivalent set up :) pry it out of my cold dead fingers you hear! :) -- - 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:43:00 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Tuesday, December 13, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:16:08 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi 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? yes. 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? gerrit is immediate inline-commenting. trac isn't :) 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. you don't have to remember. gerrit emails you asking for a review :) 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 that's reasonable... just remember... the only way you're taking make distcheck from me is by prying it out of my cold dead fingers! make distcheck will keep autofoo alive and its going away over my dead cold stinking body unlesss cmake has an equivalent set up :) pry it out of my cold dead fingers you hear! :) That is simple, alternatively we can cut off your fingers or copy distcheck's code from Autofoo ;-) -- - 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
Re: [E-devel] new build tree for efl.
On 13/12/11 12:53, Gustavo Sverzut Barbieri wrote: That is simple, alternatively we can cut off your fingers or copy distcheck's code from Autofoo ;-) How hard is implementing that anyway? Sounds fairly trivial. -- Tom -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 08:53:06 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: that's reasonable... just remember... the only way you're taking make distcheck from me is by prying it out of my cold dead fingers! make distcheck will keep autofoo alive and its going away over my dead cold stinking body unlesss cmake has an equivalent set up :) pry it out of my cold dead fingers you hear! :) That is simple, alternatively we can cut off your fingers or copy distcheck's code from Autofoo ;-) i'm going to wear cast iron gloves damnit! :) -- - 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 20:02:30 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:53:06 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: that's reasonable... just remember... the only way you're taking make distcheck from me is by prying it out of my cold dead fingers! make distcheck will keep autofoo alive and its going away over my dead cold stinking body unlesss cmake has an equivalent set up :) pry it out of my cold dead fingers you hear! :) That is simple, alternatively we can cut off your fingers or copy distcheck's code from Autofoo ;-) i'm going to wear cast iron gloves damnit! :) Makes it hard to type. I predict a slow down in your code, IRC, and email output. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, David Seikel onef...@gmail.com wrote: On Tue, 13 Dec 2011 20:02:30 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 13 Dec 2011 08:53:06 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: that's reasonable... just remember... the only way you're taking make distcheck from me is by prying it out of my cold dead fingers! make distcheck will keep autofoo alive and its going away over my dead cold stinking body unlesss cmake has an equivalent set up :) pry it out of my cold dead fingers you hear! :) That is simple, alternatively we can cut off your fingers or copy distcheck's code from Autofoo ;-) i'm going to wear cast iron gloves damnit! :) Makes it hard to type. I predict a slow down in your code, IRC, and email output. He is a 2 finger typer, that won't make a difference for him. -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 09:46:41 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: i'm going to wear cast iron gloves damnit! :) Makes it hard to type. I predict a slow down in your code, IRC, and email output. He is a 2 finger typer, that won't make a difference for him. 2 fingers or 2 fists... i can type all the same... MUAHHAHAHAHAHAHAHAHAHAHAHA! -- - 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
Re: [E-devel] new build tree for efl.
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) --enable-amalgamation (gcc can now do link time optimizations and frankly i think many amalgamated builds are broken for efl anyway). --enable-mempool-chaine--disable-logd-pool (always compile support) --enable-mempool-fixed-bitmap (always compile support) --enable-mempool-pass-through (always compile support) --enable-mempool-buddy (always compile support) --enable-mempool-one-big (always compile support) --enable-voltron (hehehe yes - amusing... but we can add easter-eggs back in later) --disable-log (no - we should always compile log capabilities) 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: --enable-e17 --enable-tests --enable-benchmark --enable-build-examples --enable-install-examples that's a lot that could go in eina already... :) i've already think about that. And I plan, as I said, to allow the user to select the libs Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tuesday, December 13, 2011, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Define less powerful. Actually for your win32 case it's more powerful ;-) Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. That is the point, if we succeed to show it is simple enough that more people will understand. Being realistic there are few developers aside you, raster and me that hack those m4/e*.m4 :-( You'll like cmake, it's very simple and easy to use. Vincent -- 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 -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 1:24 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tuesday, December 13, 2011, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Define less powerful. Actually for your win32 case it's more powerful ;-) why ? It works on windows, cross compilation works. So there is no benefits. Don't mention the visual studio support : vc++ can not compile correctly some parts of the EFL, so it's irrelevant. Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. That is the point, if we succeed to show it is simple enough that more people will understand. Being realistic there are few developers aside you, raster and me that hack those m4/e*.m4 :-( You'll like cmake, it's very simple and easy to use. I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? It will in the end do exactly the same thing, but with less power: * portability (you just need a shell with a, autotool tarball, nothing more, no tweaks) * cross compilation (cmake is bad at that, it's working fine with the autotools) * you can't build at the same time static and shared lib with cmake * i've never succeeded in using cmake on windows And there is absolutely NO chance that I will help someone with a possible cmake build system, whatever your arguments will be. Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 11:01 AM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 1:24 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tuesday, December 13, 2011, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Define less powerful. Actually for your win32 case it's more powerful ;-) why ? It works on windows, cross compilation works. So there is no benefits. Don't mention the visual studio support : vc++ can not compile correctly some parts of the EFL, so it's irrelevant. Actually not, it's a different problem. Resolving it does not resolve the other, that is right, but at least another problem is solved. I've heard that Intel has some interest to have their AppUp Encapsulator translated to EFL/WebKit-EFL and that means Windows. If that turns to be true I see they helping this part of the port, then compiling native for win32 is something they could help, then this other problem will be solved as well. Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. That is the point, if we succeed to show it is simple enough that more people will understand. Being realistic there are few developers aside you, raster and me that hack those m4/e*.m4 :-( You'll like cmake, it's very simple and easy to use. I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. We could all stick to CVS, it was doing its work correctly, yet we moved to SVN because it was easier and offered some extras. It's the same thing for autoconf-cmake. It will in the end do exactly the same thing, but with less power: * portability (you just need a shell with a, autotool tarball, nothing more, no tweaks) Same thing. If you distribute the generated Makefiles, all you need is that. Anyway, the recommended way is to distribute the original cmake files (as we distribute configure.ac and Makefile.am). * cross compilation (cmake is bad at that, it's working fine with the autotools) I keep seeing people saying that, I have no proves of that. We've tons of projects doing cross compile without any problems. From people that cross compile WebKit-EFL to all KDE crew... what's the point in this FUD? * you can't build at the same time static and shared lib with cmake Yes you can, just define two targets. ah, that reminds me of an excellent point: no libtool sucker to bug. * i've never succeeded in using cmake on windows And there is absolutely NO chance that I will help someone with a possible cmake build system, whatever your arguments will be. if you bother to say what you did, we can help you. acidx just pointed me here at the office that the WebKit WindowsCE port also uses our cmake infrastructure. Then it's yet-another-weirdo system to prove its portability and lack of cross compile issues. BlackBerry's WebKit port is also full of non-standard things and is cross compiled. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 11:28:23 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 11:01 AM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 1:24 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tuesday, December 13, 2011, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Define less powerful. Actually for your win32 case it's more powerful ;-) why ? It works on windows, cross compilation works. So there is no benefits. Don't mention the visual studio support : vc++ can not compile correctly some parts of the EFL, so it's irrelevant. Actually not, it's a different problem. Resolving it does not resolve the other, that is right, but at least another problem is solved. I've heard that Intel has some interest to have their AppUp Encapsulator translated to EFL/WebKit-EFL and that means Windows. If that turns to be true I see they helping this part of the port, then compiling native for win32 is something they could help, then this other problem will be solved as well. Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. That is the point, if we succeed to show it is simple enough that more people will understand. Being realistic there are few developers aside you, raster and me that hack those m4/e*.m4 :-( You'll like cmake, it's very simple and easy to use. I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. We could all stick to CVS, it was doing its work correctly, yet we moved to SVN because it was easier and offered some extras. It's the same thing for autoconf-cmake. It will in the end do exactly the same thing, but with less power: * portability (you just need a shell with a, autotool tarball, nothing more, no tweaks) Same thing. If you distribute the generated Makefiles, all you need is that. Anyway, the recommended way is to distribute the original cmake files (as we distribute configure.ac and Makefile.am). * cross compilation (cmake is bad at that, it's working fine with the autotools) I keep seeing people saying that, I have no proves of that. We've tons of projects doing cross compile without any problems. From people that cross compile WebKit-EFL to all KDE crew... what's the point in this FUD? * you can't build at the same time static and shared lib with cmake Yes you can, just define two targets. ah, that reminds me of an excellent point: no libtool sucker to bug. * i've never succeeded in using cmake on windows And there is absolutely NO chance that I will help someone with a possible cmake build system, whatever your arguments will be. if you bother to say what you did, we can help you. acidx just pointed me here at the office that the WebKit WindowsCE port also uses our cmake infrastructure. Then it's yet-another-weirdo system to prove its portability and lack of cross compile issues. BlackBerry's WebKit port is also full of non-standard things and is cross compiled. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I agree with Vincent here. He's worked very hard to ensure that we continue to have a functioning autotools build system, and IMO he's done a great job in that regard. The ONLY thing that would change if we switched to cmake (by your own words, since you've acknowledged that cmake and autotools are functionally equivalent) is that we'd be marginalizing the skills of a man who has spent hundreds of hours working on build systems for us of his own volition. If you are really set on using cmake, write and maintain a cmake build system alongside the autotools system for a bit IMO. Then we can make an accurate comparison where everyone knows the differences. It also prevents any hard feelings while allowing you to push the agenda that you are so attached to. -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 11:36 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Tue, 13 Dec 2011 11:28:23 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 11:01 AM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 1:24 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tuesday, December 13, 2011, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 Could we also move to cmake? thjere is no interest in having both buid systems, except pain. cmake is in addition less powerful than the autotools Define less powerful. Actually for your win32 case it's more powerful ;-) why ? It works on windows, cross compilation works. So there is no benefits. Don't mention the visual studio support : vc++ can not compile correctly some parts of the EFL, so it's irrelevant. Actually not, it's a different problem. Resolving it does not resolve the other, that is right, but at least another problem is solved. I've heard that Intel has some interest to have their AppUp Encapsulator translated to EFL/WebKit-EFL and that means Windows. If that turns to be true I see they helping this part of the port, then compiling native for win32 is something they could help, then this other problem will be solved as well. Now, i play the dictator game: If cmake is added, i stop to maintain the autotools. That is the point, if we succeed to show it is simple enough that more people will understand. Being realistic there are few developers aside you, raster and me that hack those m4/e*.m4 :-( You'll like cmake, it's very simple and easy to use. I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. We could all stick to CVS, it was doing its work correctly, yet we moved to SVN because it was easier and offered some extras. It's the same thing for autoconf-cmake. It will in the end do exactly the same thing, but with less power: * portability (you just need a shell with a, autotool tarball, nothing more, no tweaks) Same thing. If you distribute the generated Makefiles, all you need is that. Anyway, the recommended way is to distribute the original cmake files (as we distribute configure.ac and Makefile.am). * cross compilation (cmake is bad at that, it's working fine with the autotools) I keep seeing people saying that, I have no proves of that. We've tons of projects doing cross compile without any problems. From people that cross compile WebKit-EFL to all KDE crew... what's the point in this FUD? * you can't build at the same time static and shared lib with cmake Yes you can, just define two targets. ah, that reminds me of an excellent point: no libtool sucker to bug. * i've never succeeded in using cmake on windows And there is absolutely NO chance that I will help someone with a possible cmake build system, whatever your arguments will be. if you bother to say what you did, we can help you. acidx just pointed me here at the office that the WebKit WindowsCE port also uses our cmake infrastructure. Then it's yet-another-weirdo system to prove its portability and lack of cross compile issues. BlackBerry's WebKit port is also full of non-standard things and is cross compiled. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I agree with Vincent here. He's worked very hard to ensure that we continue to have a functioning autotools build system, and IMO he's done a great job in that regard. The ONLY thing that would change if we switched to cmake (by your own words, since you've acknowledged that cmake and autotools are functionally equivalent) is that we'd be marginalizing the skills of a man who has spent hundreds of hours working on build systems for us of his own volition. Indeed Vincent did an amazing work there, I'm not trying to ignore or diminish that in any way. I'm grateful for his work. But the thing is that his work was just required because autofoo is a bitch and needs tons of work more, and is so painful most people will just ignore it and do crap stuff. So it is required that brave people such as Vincent uses lots of time and effort to fix it. If you are really set on using cmake, write and maintain a cmake build system alongside the autotools system for a bit IMO. Then we can make an accurate comparison where everyone knows the differences. It also prevents any hard feelings while allowing you to push the agenda that you are so attached to. that's the proposal so far :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 2:36 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: If you are really set on using cmake, write and maintain a cmake build system alongside the autotools system for a bit IMO. Then we can make an accurate comparison where everyone knows the differences. It also prevents any hard feelings while allowing you to push the agenda that you are so attached to. just again to be sure : cmake in svn, even for testing purpose == i give up the maintance of the autotools. Because if it hits svn, i'm pretty sure it will stay forever Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. 3. it does not help with generation of your windows packages, cmake generates it and other helpers for the unpackaged distributions (rpm at least). 4. it is hard to maintain (see #1). 5. it is hard to customize and extend (see #1) All in all, everything that is being used now works... otherwise it wouldn't be used, that's for sure. So it's moot point saying that we can't change because it's there and is working. This is the same argument for CVS-SVN-GIT, etc. If we had a custom shell script of makefile, it would be working... yet it would not be the best solution. Aside from autofoo is there and works, why should we stick to it? Once we do the cmake it will be there and will work. What would account for autofoo? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. 3. it does not help with generation of your windows packages, cmake generates it and other helpers for the unpackaged distributions (rpm at least). see 2. 4. it is hard to maintain (see #1). not for me 5. it is hard to customize and extend (see #1) not for me again, it's a matter of learning a langage. Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. We'll stay and help, it's not a drop and run thing. Don't worry. And as for learning the language. I do know, both actually. Some of the helper m4 files were written by me, like the optional plugin used by e17. I can guarantee you, I just came to like cmake after I tried it. And even being autofoo person since 1998 I find my way easier on cmake than autofoo. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. Yes, for the current solution. But is that the final solution? Wouldn't it be better to integrate more natively with win32 apis if there was manpower to help fix the VS bugs? 3. it does not help with generation of your windows packages, cmake generates it and other helpers for the unpackaged distributions (rpm at least). see 2. 4. it is hard to maintain (see #1). not for me 5. it is hard to customize and extend (see #1) not for me again, it's a matter of learning a langage. compare adding an option at autoconf and cmake: cmake: OPTION(NAME Some documentation for help INIT_VAL) autoconf: AC_ARG_ENABLE(NAME, AC_HELP_STRING([--enable-NAME], [Some documentation for help @:@default=detect@:@]), [NAME=$enableval], [NAME=INIT_VAL] ) seems very close, right? but if someone drops [] it will work, except in some cases that requires quotes, etc. It's tricky. Needless to say there is no such thing as variable types in autoconf, that prevents people to create nice GUI for it, for cmake people have at least an ncurses and qt! You can have it to present checkboxes or even file dialogs to choose paths. If you want to choose cache for variables, painful with autoconf... then we don't do it and we actually remove config.cache! Take a look at: http://svn.webkit.org/repository/webkit/trunk/CMakeLists.txt # our configure.ac http://svn.webkit.org/repository/webkit/trunk/Source/cmake/ # our m4/ As webkit is a complex software with different ports (different features, versions...), each port keeps options in separate: http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsCommon.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsEfl.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsWinCE.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsBlackBerry.cmake I doubt you can't read or hack those. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. We'll stay and help, it's not a drop and run thing. Don't worry. And as for learning the language. I do know, both actually. Some of the helper m4 files were written by me, like the optional plugin used by e17. I can guarantee you, I just came to like cmake after I tried it. And even being autofoo person since 1998 I find my way easier on cmake than autofoo. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. Yes, for the current solution. But is that the final solution? Wouldn't it be better to integrate more natively with win32 apis if there was manpower to help fix the VS bugs? fixing bugs ? well, it's mainly about asm : the syntax is different (intel vs ATT). If you want to support both syntaxes and yes, there's also some of the c99 features used in the efl and not supported by vc++. Feel free to fix them. I prefer cross compiling, nowadays again, it's a matter of learning a langage. compare adding an option at autoconf and cmake: cmake: OPTION(NAME Some documentation for help INIT_VAL) autoconf: AC_ARG_ENABLE(NAME, AC_HELP_STRING([--enable-NAME], [Some documentation for help @:@default=detect@:@]), [NAME=$enableval], [NAME=INIT_VAL] ) seems very close, right? but if someone drops [] it will work, except in some cases that requires quotes, etc. It's tricky. I forgot to say : is there a --help option with cmake ? Needless to say there is no such thing as variable types in autoconf, that prevents people to create nice GUI for it, for cmake people have at least an ncurses and qt! You can have it to present checkboxes or even file dialogs to choose paths. If you want to choose cache for variables, painful with autoconf... then we don't do it and we actually remove config.cache! Take a look at: http://svn.webkit.org/repository/webkit/trunk/CMakeLists.txt # our configure.ac http://svn.webkit.org/repository/webkit/trunk/Source/cmake/ # our m4/ As webkit is a complex software with different ports (different features, versions...), each port keeps options in separate: http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsCommon.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsEfl.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsWinCE.cmake http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsBlackBerry.cmake nice try : i won't look at those files... Vincent -- 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
Re: [E-devel] new build tree for efl.
2011/12/13 Cedric BAIL cedric.b...@free.fr: On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: +1 You are getting to much social :-) Could we also move to cmake? How about git? I can have people to help with both. We did the webkit EFL cmake in short time, can do for EFL as well. Thanks for taking this long due change! First about git. Today tool provided to do review and managing branch are just amazing. I am thinking about gerrit, but also github and gittorrious. So if we switch to git, we need to have this kind of tool so it will be usefull. I see it will be also much more easy to do backport. So I am now on the side that if we describe properly how to contribute after switching to git, the tool are now great and it's worth doing the switch. I would just postpone it until we do release e17, elm, eio, ethumb and emotion. Many people will be happy ;-) http://doodle.com/h9dgtwbhhtv5c9sw - Finally, I can delete that poll. About cmake, I don't know its current status, but in the past I did suffer from its lack of portability and limitation to do cross compilation. Before any switch to it, I want to be sure that all this issue are solved. That we will be able to provide a working build on all our target system and that we can easily do all cross compilation. -- 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 -- Leif -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 1:32 AM, Carsten Haitzler ras...@rasterman.comwrote: 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. Not trying to derail the thread into something related to the original topic, but is there a tentative date for such change? How will it be done? Best regards, Luis Felipe 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.ac and 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 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 -- Luís Felipe Strano Moraes http://www.strano.org -- 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
Re: [E-devel] new build tree for efl.
On 13/12/11 20:21, Luis Felipe Strano Moraes wrote: Not trying to derail the thread into something related to the original topic, but is there a tentative date for such change? How will it be done? I believe it'll wait until the move to git as that move will already shuffle everything around. Also, git will allow us to save the history of the files... -- Tom. -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 4:32 PM, Tom Hacohen t...@stosb.com wrote: On 13/12/11 20:21, Luis Felipe Strano Moraes wrote: Not trying to derail the thread into something related to the original topic, but is there a tentative date for such change? How will it be done? I believe it'll wait until the move to git as that move will already shuffle everything around. Also, git will allow us to save the history of the files... Hmm, I might be a bit overdosing in caffeine right now, but from what I understood this was to be done prior to the release of E17, and the move to git will be after this earth-shattering event. I asked about how it will be done because I see two different issues here: 1) Shuffling of directories will involve major work in autotools; 2) Moving to git will require major work on the server side (trying to keep history somewhat sane, changing the scripts that deal with devs, commit-list, gerrit, etc.) --lf -- Tom. -- Luís Felipe Strano Moraes http://www.strano.org -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 4:48 PM, Tom Hacohen t...@stosb.com wrote: On 13/12/11 20:47, Luis Felipe Strano Moraes wrote: Hmm, I might be a bit overdosing in caffeine right now, but from what I understood this was to be done prior to the release of E17, and the move to git will be after this earth-shattering event. We also chatted about it in IRC a bit and for the reasons I mentioned it seems that this move will happen only after the move to git and thus after e17 is out. Or at least that's what I got from our chat on IRC. Oh, good to know. And good to be announced to the mailing list as well :) Thanks for the info Tom :) --lf -- Tom. -- Luís Felipe Strano Moraes http://www.strano.org -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 1:31 PM, Vincent Torri vincent.to...@gmail.com wrote:
On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri vincent.to...@gmail.com
wrote:
On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com
wrote:
On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I would actually like you to answer that question: why moving to cmake
if the autotools are already doing the job correctly ?
Doing it correctly may not be enough.
you didn't answer to that question. you just give vague comparison. So
what's no enough ?
1. it is utterly complicated for what it does, m4 macros are a hell,
the shell commands to be portable must be restricted from gnu-isms and
likely we fail at that from time to time.
it's a hell for you, maybe. I've tried to twek cmake files, and i
didn't undrestand how to do what i wanted. It's a matter of learning a
langage.
We'll stay and help, it's not a drop and run thing. Don't worry.
And as for learning the language. I do know, both actually. Some of
the helper m4 files were written by me, like the optional plugin used
by e17.
I can guarantee you, I just came to like cmake after I tried it. And
even being autofoo person since 1998 I find my way easier on cmake
than autofoo.
2. it does not generate native build systems, which is not a problem
for the way we handle win32/mac ports at the moment, but it may not be
sufficient in the future.
for win32, i've already replied.
Yes, for the current solution. But is that the final solution?
Wouldn't it be better to integrate more natively with win32 apis if
there was manpower to help fix the VS bugs?
fixing bugs ? well, it's mainly about asm : the syntax is different
(intel vs ATT). If you want to support both syntaxes
and yes, there's also some of the c99 features used in the efl and not
supported by vc++. Feel free to fix them. I prefer cross compiling,
nowadays
again, it's a matter of learning a langage.
compare adding an option at autoconf and cmake:
cmake:
OPTION(NAME Some documentation for help INIT_VAL)
autoconf:
AC_ARG_ENABLE(NAME,
AC_HELP_STRING([--enable-NAME], [Some documentation for help
@:@default=detect@:@]),
[NAME=$enableval],
[NAME=INIT_VAL]
)
seems very close, right? but if someone drops [] it will work, except
in some cases that requires quotes, etc. It's tricky.
I forgot to say : is there a --help option with cmake ?
Needless to say there is no such thing as variable types in autoconf,
that prevents people to create nice GUI for it, for cmake people have
at least an ncurses and qt! You can have it to present checkboxes or
even file dialogs to choose paths.
If you want to choose cache for variables, painful with autoconf...
then we don't do it and we actually remove config.cache!
Take a look at:
http://svn.webkit.org/repository/webkit/trunk/CMakeLists.txt # our
configure.ac
http://svn.webkit.org/repository/webkit/trunk/Source/cmake/ # our m4/
As webkit is a complex software with different ports (different
features, versions...), each port keeps options in separate:
http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsCommon.cmake
http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsEfl.cmake
http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsWinCE.cmake
http://svn.webkit.org/repository/webkit/trunk/Source/cmake/OptionsBlackBerry.cmake
nice try : i won't look at those files...
How about looking at a patch? I've converted Embryo to CMake to make a
case, find attached file.
Supposedly it does the same as configure.ac and others, unless I've
missed some thing. Of course I could not test with evil, but the rule
is there.
See how simple it is, it's readable. And this is not accounting any
helper files such as our efl_*.m4, in real world we should move
common bits to it. Also notice that some automatically created defines
we use from autofoo changed names, then I'm doing the remap on the
cmake, but it could be changed in the source code.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Index: src/lib/CMakeLists.txt
===
--- src/lib/CMakeLists.txt (revision 0)
+++ src/lib/CMakeLists.txt (revision 0)
@@ -0,0 +1,30 @@
+LIST(APPEND LIBEMBRYO_SOURCES
+ embryo_amx.c
+ embryo_args.c
+ embryo_float.c
+ embryo_main.c
+ embryo_rand.c
+ embryo_str.c
+ embryo_time.c
+ )
+
+LIST(APPEND LIBEMBRYO_LIBS ${EINA_LIBRARIES} ${EVIL_LIBRARIES})
+
+IF(SHARED_LIBS)
+ ADD_LIBRARY(so_embryo SHARED ${LIBEMBRYO_SOURCES})
+ TARGET_LINK_LIBRARIES(so_embryo
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 1:31 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. We'll stay and help, it's not a drop and run thing. Don't worry. And as for learning the language. I do know, both actually. Some of the helper m4 files were written by me, like the optional plugin used by e17. I can guarantee you, I just came to like cmake after I tried it. And even being autofoo person since 1998 I find my way easier on cmake than autofoo. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. Yes, for the current solution. But is that the final solution? Wouldn't it be better to integrate more natively with win32 apis if there was manpower to help fix the VS bugs? fixing bugs ? well, it's mainly about asm : the syntax is different (intel vs ATT). If you want to support both syntaxes and yes, there's also some of the c99 features used in the efl and not supported by vc++. Feel free to fix them. I prefer cross compiling, nowadays again, it's a matter of learning a langage. compare adding an option at autoconf and cmake: cmake: OPTION(NAME Some documentation for help INIT_VAL) autoconf: AC_ARG_ENABLE(NAME, AC_HELP_STRING([--enable-NAME], [Some documentation for help @:@default=detect@:@]), [NAME=$enableval], [NAME=INIT_VAL] ) seems very close, right? but if someone drops [] it will work, except in some cases that requires quotes, etc. It's tricky. I forgot to say : is there a --help option with cmake ? couple of interesting variants, see http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide # similar to ./configure --help, show variables, defaults and documentation string cmake $DIR -LH # similar to linux kernel make config cmake $DIR -i # similar to linux kernel make menuconfig # http://www.cmake.org/cmake/img/ccmake.png ccmake $DIR # similar to linux kernel make xconfig # http://screenshots.debian.net/package/cmake-qt-gui cmake-gui $DIR -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 8:34 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 1:31 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I would actually like you to answer that question: why moving to cmake if the autotools are already doing the job correctly ? Doing it correctly may not be enough. you didn't answer to that question. you just give vague comparison. So what's no enough ? 1. it is utterly complicated for what it does, m4 macros are a hell, the shell commands to be portable must be restricted from gnu-isms and likely we fail at that from time to time. it's a hell for you, maybe. I've tried to twek cmake files, and i didn't undrestand how to do what i wanted. It's a matter of learning a langage. We'll stay and help, it's not a drop and run thing. Don't worry. And as for learning the language. I do know, both actually. Some of the helper m4 files were written by me, like the optional plugin used by e17. I can guarantee you, I just came to like cmake after I tried it. And even being autofoo person since 1998 I find my way easier on cmake than autofoo. 2. it does not generate native build systems, which is not a problem for the way we handle win32/mac ports at the moment, but it may not be sufficient in the future. for win32, i've already replied. Yes, for the current solution. But is that the final solution? Wouldn't it be better to integrate more natively with win32 apis if there was manpower to help fix the VS bugs? fixing bugs ? well, it's mainly about asm : the syntax is different (intel vs ATT). If you want to support both syntaxes and yes, there's also some of the c99 features used in the efl and not supported by vc++. Feel free to fix them. I prefer cross compiling, nowadays again, it's a matter of learning a langage. compare adding an option at autoconf and cmake: cmake: OPTION(NAME Some documentation for help INIT_VAL) autoconf: AC_ARG_ENABLE(NAME, AC_HELP_STRING([--enable-NAME], [Some documentation for help @:@default=detect@:@]), [NAME=$enableval], [NAME=INIT_VAL] ) seems very close, right? but if someone drops [] it will work, except in some cases that requires quotes, etc. It's tricky. I forgot to say : is there a --help option with cmake ? couple of interesting variants, see http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide # similar to ./configure --help, show variables, defaults and documentation string cmake $DIR -LH # similar to linux kernel make config cmake $DIR -i # similar to linux kernel make menuconfig # http://www.cmake.org/cmake/img/ccmake.png ccmake $DIR # similar to linux kernel make xconfig # http://screenshots.debian.net/package/cmake-qt-gui cmake-gui $DIR do what you want, i won't look at any cmake code, as i already said. And again, if cmake stuff reach svn even for testing purpose, i'll abandon the maitanance of the autotools and won't help with cmake at all. Vincent -- 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
[E-devel] new build tree for efl.
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.ac and 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 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 12:32:00 +0900 Carsten Haitzler (The Rasterman) 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). Will this mean that, for example my embedded project that only uses eina eet evas ecore embryo edje, will have to get a lot bigger? Or can I easily choose the components I build and install, even if I have to put up with a bigger source tarball? So long as I still get to easily cut out the stuff my embedded project does not require, like IMF and X support. Though I don't see where eeze, efreet, e_dbus, eio, emotion, or elementary would fit into my upcoming big desktop app either. Well, maybe emotion. 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. This I agree with. I can see lots of arguments coming though. benefits: 1. massively reduced release workload. Great. 2. massively better documentation as it now will be a single document for all of efl nicely cross-referenced between each actual lib Good, I had a problem in documenting the edje lua stuff, a lot of it needed to reference evas and other libraries. My doxygen skills are limited, was not sure how to do that. 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 All good things. 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. Personally I think it should still be split a little further. eina eet evas ecore embryo edje is good for embedded work that a frame buffer is a good match for. Not everything needs X or desktop stuff. The rest could be X desktop and toolkit. You could use elementary without needing anything other than eina eet evas ecore embryo edje for instance. Efreet and e_dbus I would put into misc. Not so sure about eeze and eio, I'm not actually familar with them. You'll get lots of people arguing the split though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 14:02:00 +1000 David Seikel onef...@gmail.com said: On Tue, 13 Dec 2011 12:32:00 +0900 Carsten Haitzler (The Rasterman) 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). Will this mean that, for example my embedded project that only uses eina eet evas ecore embryo edje, will have to get a lot bigger? Or can I easily choose the components I build and install, even if I have to put up with a bigger source tarball? you'd have to choose components from the installed files. eg only include the libs/modules/headers you need. this may end up compiling more than you need - but so be it. So long as I still get to easily cut out the stuff my embedded project does not require, like IMF and X support. Though I don't see where eeze, efreet, e_dbus, eio, emotion, or elementary would fit into my upcoming big desktop app either. Well, maybe emotion. 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. This I agree with. I can see lots of arguments coming though. it's happening... so the arguments against are just going to create noise. helping and going with the flow will be constructive. :) benefits: 1. massively reduced release workload. Great. 2. massively better documentation as it now will be a single document for all of efl nicely cross-referenced between each actual lib Good, I had a problem in documenting the edje lua stuff, a lot of it needed to reference evas and other libraries. My doxygen skills are limited, was not sure how to do that. now that's moot as its a single efl doc with everything cross-linked as its the one doxygen build. :) 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 All good things. 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. Personally I think it should still be split a little further. eina eet evas ecore embryo edje is good for embedded work that a frame buffer is a good match for. Not everything needs X or desktop stuff. The rest could be X desktop and toolkit. You could use elementary without needing anything other than eina eet evas ecore embryo edje for instance. Efreet and e_dbus I would put into misc. Not so sure about eeze and eio, I'm not actually familar with them. You'll get lots of people arguing the split though. no - it's going into the one efl blob. :) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- - 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
Re: [E-devel] new build tree for efl.
On Tue, Dec 13, 2011 at 5:02 AM, David Seikel onef...@gmail.com wrote: On Tue, 13 Dec 2011 12:32:00 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: Personally I think it should still be split a little further. eina eet evas ecore embryo edje is good for embedded work that a frame buffer is a good match for. Not everything needs X or desktop stuff. The rest could be X desktop and toolkit. You could use elementary without needing anything other than eina eet evas ecore embryo edje for instance. Efreet and e_dbus I would put into misc. Not so sure about eeze and eio, I'm not actually familar with them. You'll get lots of people arguing the split though. adding configure options to build only some lib is easy (of course, with dependency management). Vincent -- 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
Re: [E-devel] new build tree for efl.
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) In order to simplify even more, why not merging embryo in edje tree (so having edje/src/lib/embryo for libembryo and edje/src/bin/embryo for the binary) ? Vincent -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 06:47:09 +0100 Vincent Torri vincent.to...@gmail.com wrote: 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) In order to simplify even more, why not merging embryo in edje tree (so having edje/src/lib/embryo for libembryo and edje/src/bin/embryo for the binary) ? Good idea. It's not used separately. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] new build tree for efl.
On Tue, 13 Dec 2011 06:47:09 +0100 Vincent Torri vincent.to...@gmail.com said: 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) In order to simplify even more, why not merging embryo in edje tree (so having edje/src/lib/embryo for libembryo and edje/src/bin/embryo for the binary) ? it doesn't much matter once its in 1 tree. i'd keep the name split for familiarity reasons so people can find what they used to find in the same place. -- - 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
