On Sat, 17 Dec 2011 05:14:21 -0500 Youness Alaoui <[email protected]> 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 <[email protected]> wrote: > > > On Wed, 14 Dec 2011 13:40:16 -0200 Iván Briano (Sachiel) > > <[email protected]> wrote: > > > > > 2011/12/14 Cedric BAIL <[email protected]>: > > > > 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 > > [email protected] > > 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 > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
