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 AT&T). 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
