On 12/13/2011 04:31 PM, Vincent Torri 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 ?
unfortunately cmake --help is not equivalent to configure --help. Moreover I find the cmake syntax for the options a bit annoying. For the rest, well I am not using cmake often enough to really have constructive criticism but I would stick to autofoo tools since everything is already written and working. Mathieu ------------------------------------------------------------------------------ Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
