On Fri, 5 Mar 2010, Vincent Torri wrote:
On Fri, 5 Mar 2010, Gustavo Sverzut Barbieri wrote:
On Fri, Mar 5, 2010 at 3:35 PM, Carsten Haitzler <[email protected]>
wrote:
On Fri, 5 Mar 2010 19:10:55 +0100 (CET) Vincent Torri
<[email protected]>
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
benchmarks of various building frameworks
http://retropaganda.info/~bohan/work/sf/psycle/branches/bohan/wonderbuild/benchmarks/time.xml
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
