On 03/03/12 20:10, Vincent Torri wrote: > that's my last mail about cmake: > > 0) If you read my previous message, i talked about cmake in the core > EFL. I know that Ecrire is not part of them... thank you...
I know you talked about it in the core efl, but as we both pointed out, ecrire is not part of the core efl, so there was no reason for you to raise the subject. > > 1) build systems are for developpers. 99.9% of users don't care about > build systems as they use the packages of their distro. So "people > *do* use cmake in the outside world, and shipping does could be nice > for them" is not a good argument imho. I'm sorry for not being clear enough in my previous email, I said shipping FindEina.cmake and the such would be nice (they are like pkg-config for cmake) as other developers who write code create their projects using cmake (me for example?) and it would be easier for them to do find_pkg(Eina) instead of using the pkg_config wrapping cmake macros. > > 2) maintaining 2 build systems is STUPID : it is more work. We have to > sync them. We are not enough to even finish e17, so loosing time in > maintaining another build system is a waste of time. I have > participated in several projects using both autotools and cmake and it > has always been a mess. But maybe you just want to replace the > autotools by cmake... No one every said anything about maintaining two build systems. I just said, if that's where progress will take us to at some point, so be it. Maybe it won't, maybe we'll use scones ;P > > 3) the autotools are already here and are working Again, not arguing about core efl, but that's not a strong enough point. > > 4) i've never successfully succeeded in using cmake on Windows. I have, and many others have (not efl). > > 5) to add the same functionalities than the autotools you have to add > plenty of stuff (just distcheck and help...). So it's error prone. Only distcheck and dist I think, but either way, it's not that hard to do. And if someone wants to do it, it's their choice. > > 6) cmake is less portable than autotools : autotools basically need a > shell and some widely used programs (awk and/or perl, iirc). Cmake depends on nothing and is available for all platforms, autofoo on the other hand is not, and perl is not that standard on all platforms. > > 7) I'm not the only one who think the same about cmake. I don't really have a strong opinion either way, I just think personally that cmake is better and I'd like to give it a chance. Also, I don't like eliminating possibly better options just because. > > And it's not a "veto". The project has started without me and can be > finished without me. Or not finish and continue forever? :P But anyhow, it's still a veto because we want you on the team, and this change will probably not be done with your statement still holding. > >> Also, I'm very disappointed you won't look at ecrire's code because of >> such nonsense hate for cmake. > > just read the last thread about cmake and my pov. That's not the first > time that this discussion has been started and it will more or less > explain my decision. I read it at the time (too long to read it again just for that), but I don't get why you wouldn't want to send patches for the C files (a.k.a code) just because there are a couple of cmake files in the repo. I plan on adding the Cmake pkg-config stuff to core EFL, and I hope you won't be mad about it (if you will, please let me know and I won't do it). It's there for *other projects* using cmake that may be interested in EFL (Samsung heavily uses cmake). If you have no objections, I plan on doing it in the next couple of days. -- Tom. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
