On Tue, Dec 13, 2011 at 8:34 PM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On Tue, Dec 13, 2011 at 1:31 PM, Vincent Torri <[email protected]> > wrote: >> On Tue, Dec 13, 2011 at 4:21 PM, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >>> On Tue, Dec 13, 2011 at 12:54 PM, Vincent Torri <[email protected]> >>> wrote: >>>> On Tue, Dec 13, 2011 at 3:44 PM, Gustavo Sverzut Barbieri >>>> <[email protected]> wrote: >>>>> On Tue, Dec 13, 2011 at 12:35 PM, Vincent Torri <[email protected]> >>>>> wrote: >>>>>> On Tue, Dec 13, 2011 at 2:28 PM, Gustavo Sverzut Barbieri >>>>>> <[email protected]> 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
do what you want, i won't look at any cmake code, as i already said. And again, if cmake stuff reach svn even for testing purpose, i'll abandon the maitanance of the autotools and won't help with cmake at all. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
