I just ran a gcc trunk build. The configure line was CC="clang" CXX="clang++" \ ../trunk.year/configure --prefix=/home/dcb38/gcc/results.$DATE.asan.ubsan \ --disable-multilib \ --disable-bootstrap \ --with-build-config=bootstrap-asan \ --with-build-config=bootstrap-ubsan \ --with-pkgversion=$HASH \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran The command I used was $ (date;make -j 20;date) > mk.out 2>&1 $ grep "checking for" mk.out | sort -k 2 | uniq -c | sort -rn > 1.out $ head 1.out 20 checking for C compiler default output file name... a.out 19 checking for a BSD-compatible install... /usr/bin/install -c 18 checking for egrep... /usr/bin/grep -E 17 checking for x86_64-pc-linux-gnu-ranlib... ranlib 17 checking for x86_64-pc-linux-gnu-ar... ar 17 checking for unistd.h... (cached) yes 15 checking for x86_64-pc-linux-gnu-objdump... objdump 15 checking for minix/config.h... no 14 checking for gawk... gawk 12 checking for x86_64-pc-linux-gnu-gcc... clang That seems a lot of redundant checking to me. Perhaps the build process could be made faster by only checking some properties once and remembering the result for later ?
I doubt configure is where most of the time is spent these days.
A lot of that's just the way that autoconf works. You'd probably have to change the upstream implementation of certain autoconf macros to fix this. Alternatively, you could also try configuring with the "-C" flag to your configure script, which should cause configure results to be cached, but that can be rather fragile, as the config.cache files can stop your build if the slightest things to change. I suppose GCC could try sharing its config.cache files more widely between its various subdirectories, but that would be somewhat risky, given that some of the things that configure checks for could change due to the whole bootstrap process (fixincludes changes the headers available, the new compiler getting built changes which compiler should be found, and what features it has, the new runtime libraries getting built change what functions are available, and so on...)
There's some stuff we could cache for sure but it wouldn't be the majority of the checks - stuff like finding tools like awk, sed should work regardless of which stage we're in and so on.
(In reply to Sam James from comment #3) > There's some stuff we could cache for sure but it wouldn't be the majority > of the checks - stuff like finding tools like awk, sed should work > regardless of which stage we're in and so on. gawk and sed were potential host modules at one point previously, too, but it looks like they've been removed, so yeah I guess it'd be safe for them now... anything that might fall in this category should get checked against Makefile.def to make sure there aren't already potential modules for them for people trying to combine trees or something...