On Sat, 6 Mar 2010 00:53:32 +0300 Andrian Nord <[email protected]> said:
> On Sat, Mar 06, 2010 at 05:35:46AM +1100, Carsten Haitzler 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. > > Ok, I see your point. But really, packaging binaries is not what gentoo > makes, so: no, thanks. And, about configure - guess what - that's why > cache exists, it will speedup futher configures. Also, some current > configures hardly unoptimal, as I see, some of them still checking > features of fortran, c++ and soon. thats fairly minimial in the configure - and part of standard macros sucked in for standard checks. even with caches - if used right, it will extend build times badly. > Ok, that's seems to be meaningless talk, if we will have some example > build system, I'll told you about real results and perfomance. sure! if you can demonstrate that this has minimal impact - i'm willing to look at it. but i suspect that's not going to happen :) if you are unwilling to package up the modules as thats not the gentoo way - then you deal with the rebuild... but then again - it's gentoo... you have already said "deal with it - anything you install will take a long time as full source needs downloading and compiling" so you've already accepted a massive install cost as a direct result of selecting gentoo. so it's within the cost structure of your OS. you could just delete the modules you don't want after installation. > > 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 > > Maybe then migrate to cmake if you hate autofoo so much? Just in case... we are not migrating to anything at this stage. we are talking of doing EFL alpha 1.0 releases - we're not doing any major surgery to the build system. it stays. i was just saying that autofoo is frustrating and slow enough as-is and there is no desire to make it more-so than really needed. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
