On Tue, Dec 13, 2011 at 11:01 AM, Vincent Torri <[email protected]> wrote: > > On Tue, Dec 13, 2011 at 1:24 PM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > On Tuesday, December 13, 2011, Vincent Torri <[email protected]> > > wrote: > >> On Tue, Dec 13, 2011 at 10:13 AM, Gustavo Sverzut Barbieri > >> <[email protected]> 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: [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
