From: Gustavo S. B. <bar...@pr...> - 2010-03-05 18:43:43
|
On Fri, Mar 5, 2010 at 3:35 PM, Carsten Haitzler <ra...@ra...> wrote: > On Fri, 5 Mar 2010 19:10:55 +0100 (CET) Vincent Torri <vt...@un...> > 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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |