On Tue, Dec 13, 2011 at 1:31 PM, Vincent Torri <vincent.to...@gmail.com> wrote: > 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 ?
couple of interesting variants, see http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide # similar to ./configure --help, show variables, defaults and documentation string cmake $DIR -LH # similar to linux kernel "make config" cmake $DIR -i # similar to linux kernel "make menuconfig" # http://www.cmake.org/cmake/img/ccmake.png ccmake $DIR # similar to linux kernel "make xconfig" # http://screenshots.debian.net/package/cmake-qt-gui cmake-gui $DIR -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
