On Fri, Mar 5, 2010 at 7:54 PM, Vincent Torri <vto...@univ-evry.fr> wrote: > > > On Fri, 5 Mar 2010, Gustavo Sverzut Barbieri wrote: > >> On Fri, Mar 5, 2010 at 3:35 PM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >>> >>> On Fri, 5 Mar 2010 19:10:55 +0100 (CET) Vincent Torri >>> <vto...@univ-evry.fr> >>> said: >>> >>>> >>>> >>>> On Sat, 6 Mar 2010, Carsten Haitzler (The Rasterman) wrote: >>>> >>>>>> Also, there is a problem with 'e' - as you've merged most of usefull >>>>>> modules inside e itself, now it is very difficult to switch off/on >>>>>> some >>>>>> module (you will be forced to rebuild whole e to get just one module >>>>>> additional). If we will provide autofoo scripts with recursive >>>>>> configures, >>>>>> that will allow to fetch and build single module without e itself, >>>>>> while >>>>>> keeping possibility of controlling build options for whole e - will >>>>>> you >>>>>> accept this, or you will say "it may break someday, current scheme is >>>>>> working, let's not change it, as we don't want to test your new >>>>>> scripts"? >>>>> >>>>> thats just nuts! run a configure script per module? do you really want >>>>> to >>>>> make my build time 20x what they are now? running the configure for a >>>>> lot >>>>> of efl takes longer than the actual compile - and now run it 70 times >>>>> for >>>>> e? no thanks. build all the modules always - there is no harm to it. >>>>> package them separately if you want and allow each module to be >>>>> installed >>>>> as a package. >>>> >>>> I agree with raster. Did you ever try to build gettext ? It takes >>>> several >>>> minutes on linux to just run the configure's. I don't even talk about >>>> Windows where it takes several dozens of minutes. >>> >>> oh indeed - it'd be even worse there on windows as execcing tools in >>> configure >>> simply takes much longer on windows than linux. i'm already humongously >>> annoyed >>> at autofoo for taking so long to generate configure from configure.ac - >>> and >>> makefile.in's etc. etc. - that takes as long as configure - then >>> configure - a >>> 800kb+ shell script... god forbid.. takes yet longer... then every file >>> is >>> compiled via a monster libtool shellscript that finally execs gcc which >>> takes a >>> tiny fraction of a second. the total time actually spent compiling (in >>> gcc) >>> and not inside all the layers of generatiing autofoo from templates, >>> runing >>> configure and libtool scripts etc is probably in the order of less than >>> 5% of >>> the time to compile things for EFL. that means - you could expect a 20x >>> speedup >>> if we could ditch it. i'm already grossly disgusted with autotools and >>> its >>> seemingly infinite appetite for eating up cycles and making builds >>> longer. if >>> we were not so heavily invested - i'd search for an alternative (cmake >>> maybe?), >>> but we're here. >>> >>> if we had an autofoo compatible system that could take our existing >>> configure.ac's and makefile.am's and generate a lean, mean, and efficient >>> "configure", kill off libtoool with a simple and fast wrapper - i'd be a >>> very >>> happy man. i know i don't have the time - nor the focus to do this - so >>> i'll >>> just sit here with my eyes to heaven praying that one day such a thing >>> will >>> turn up. Hell maybe it's time to to write "build.sh" files that just hve >>> a >>> pre-defined config - spew out the config.h's and other template outputs >>> and >>> do the work. maybe we can generate them from our Makefile.am's :) maybe - >>> one >>> day... :) >> >> BTW, webkit-gtk (and now efl) is the only one using autofoo and is the >> slowest one. All the other guys are using alternative solutions, being >> google chrome the user of scons and is one of the fastest... >> >> and now to the ultimate source for denying it: it uses python! >> >> >> really, I have experience with it and could port it over... but I know >> you all would comply about it. > > waf or Perfoce Jam are also other tools that are quite good
+1 for Waf. Since I use it in my own projects, I can't get back to anything else. Lionel > > Vincent > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
