Hi folks, Just wanted to let people know that ccache works rather well with wine. On my lowly 600MHz Pentium box, it takes about 1h to compile, after a make clean. Second time through it takes about 1/4h to do the same thing, 75% faster! (As an added bonus, CPU utilization dropped from 86% to 60%) A nice thing would be to also be able to generate a top Makefile that knows all about the project, and we no longer do the recursive descent. It takes my box almost 20 seconds to do a 'make -s' after a full build. Not sure how doable this is, but I'm sure that things would be way faster if everything would be in one big Makefile. Probably I'm just going to end up buying a faster box before this gets implemented though :) How long does it take to do a 'time make -s' after a full build on one of the beefier boxes? -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
A nice thing would be to also be able to generate a top Makefile that knows all about the project, and we no longer do the recursive descent. It takes my box almost 20 seconds to do a 'make -s' after a full build. Not sure how doable this is, but I'm sure that things would be way faster if everything would be in one big Makefile. Probably I'm just going to end up buying a faster box before this gets implemented though :)
Some time ago I looked into hacking make_dlls to do this, but there were too many special cases to make it worthwhile. And on my new box the recursion takes less than 2 seconds so I no longer care <g> -- Alexandre Julliard julliard(a)winehq.com
On Mon, 29 Sep 2003, Alexandre Julliard wrote:
Some time ago I looked into hacking make_dlls to do this, but there were too many special cases to make it worthwhile.
Too bad, we have a fairly regular structure in dlls/ do you remember what the problems were?
And on my new box the recursion takes less than 2 seconds so I no longer care <g>
That's it, I hate you now! :) 10x faster!!! This box of mine is like 3 years old, man oh man... Yeah, but imagine doing that in .3s, eh? ;) -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
Some time ago I looked into hacking make_dlls to do this, but there were too many special cases to make it worthwhile.
Too bad, we have a fairly regular structure in dlls/ do you remember what the problems were?
One problem is that most makefiles specify different defines, so you basically need to have one different rule for each C file. Then there are many files that have explicit rules. It could be done, but I don't think it's worth it, and the result would be really messy and hard to maintain. -- Alexandre Julliard julliard(a)winehq.com
On Tue, 2003-09-30 at 01:40, Alexandre Julliard wrote:
One problem is that most makefiles specify different defines, so you basically need to have one different rule for each C file. Then there are many files that have explicit rules. It could be done, but I don't think it's worth it, and the result would be really messy and hard to maintain.
Maybe oneday it would be worth porting the Wine build system to SCons (http://www.scons.org/). From "What makes SCons better": * Configuration files are Python scripts--use the power of a real programming language to solve build problems. * Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types. * Built-in support for C, C++, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types. * Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce. * Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files. * Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps. * Improved support for parallel builds--like make -j but keeps N jobs running simultaneously regardless of directory hierarchy. * Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs. * Global view of all dependencies--no more multiple build passes or reordering targets to build everything. * Building from central repositories of source code and/or pre-built targets. * Ability to share built files in a cache to speed up multiple builds. * Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.
On Tue, Sep 30, 2003 at 01:16:17PM +0100, Mike Hearn wrote:
On Tue, 2003-09-30 at 01:40, Alexandre Julliard wrote:
One problem is that most makefiles specify different defines, so you basically need to have one different rule for each C file. Then there are many files that have explicit rules. It could be done, but I don't think it's worth it, and the result would be really messy and hard to maintain.
Maybe oneday it would be worth porting the Wine build system to SCons (http://www.scons.org/). From "What makes SCons better":
Woot! I was about to plug "cook" from Aegis fame, but I thought nobody likes advocacy. But if it is plugging time, "cook" is wonderful. :-) The author of "recursive make considered harmful" also authored cook. Aegis is what I use for http://vmlinux.org/jakov/Wine/ . Sure scons looks really nice too, with its support for Windows project files. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
On September 30, 2003 08:16 am, Mike Hearn wrote:
Maybe oneday it would be worth porting the Wine build system to SCons (http://www.scons.org/). From "What makes SCons better":
Whenever I look at make replacements, I always find them more cluttered/verbose/uglier, but this may be because I'm so used to make. Do you have a real-life example of a scons file (non-trivial) just to see how it looks like? -- Dimi.
Le lun 29/09/2003 à 17:35, Dimitrie O. Paun a écrit :
Hi folks,
Just wanted to let people know that ccache works rather well with wine. On my lowly 600MHz Pentium box, it takes about 1h to compile, after a make clean. Second time through it takes about 1/4h to do the same thing, 75% faster! (As an added bonus, CPU utilization dropped from 86% to 60%)
A bit OT: when configure/configure.ac is patched, I assume the next make will require a ./configure before (and hence a full make)?
How long does it take to do a 'time make -s' after a full build on one of the beefier boxes?
Athlon XP1800+ (not that beef in those Athlon64 days): Cold (ie, no Wine work since last reboot): real 16.2s user 3.8s sys 5.0s Hot (a second time just after): real 2.3s user 1.4s sys 0.6s Vincent
On 29 Sep 2003, Vincent Béron wrote:
A bit OT: when configure/configure.ac is patched, I assume the next make will require a ./configure before (and hence a full make)?
yes, it will require a configure, but chances are that it will invaldate very little in the cache, so you still get the speed advantage.
Cold (ie, no Wine work since last reboot): real 16.2s
See, there's stuff to improve here... :)
Hot (a second time just after): real 2.3s
Yeap, I hate you too! :) -- Dimi.
participants (6)
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Jakob Eriksson -
Mike Hearn -
Vincent Béron