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