Well, yes. 1 second/file is still slow! I want "make" to complete instantaneously! Don't you?
Actually I want it to complete before I even start, but I don't want to get too greedy. :)
What's really sad is that for cross-compilation of the toolchain, we
have to repeat a few steps (build gcc twice, build glibc twice)
because glibc and gcc assume that a near-complete environment is
available(such as gcc needing headers, and glibc needing -lgcc-eh), so
even really fast machines(2.4Ghz P4) take an hour to do a cross-build
from scratch.
That sounds comparable to the time required to build RTEMS toolsets. I just looked at the timestamp on the build logs for a gcc 4.0.0 CVS build with newlib 1.13.0 and it is on the order of 60-90 minutes per target on a 2.4 Ghz P4 w/512 MB RAM. This is just C and C++ and the variance is probably mostly due to the number of multilibs.
I checked build logs of gcc 3.3.5 with newlib 1.13 from December on the same machine and times were comparable so it isn't a recent slowdown.
When I built my native 4.0.0 on this machine, I did notice that compiling the Java libraries took long enough to notice and when I did a top, I noticed that gjc was running for 30+ seconds of CPU time with RSS on the order of 150 MB. Another time I noticed that sh had taken 90 seconds and that was an invocation of libtool with a very long command line.
Here is the configure command and output of time on this machine for a gcc 4.0.0 build:
../gcc-4.0.0/configure --prefix=/opt/gcc-4.0.0 --enable-languages=c,c++,ada,java,objc
4271.94user 685.49system 1:31:18elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (33176183major+40970199minor)pagefaults 0swaps
A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took 90 minutes for "make" -- not a full bootstrap.
--joel
