Adam D. Moss writes: > The only thing I can think of would be if the > <windows.h>/<windef.h>/etc headers that get pulled into just about > every file on a win32 build expand into monsterous evil and add > measurably to the unit compilation time. Well, that probably is the reason. <windows.h> *is* quite large. But none of the GLib headers, and none of the normal GTK headers include it, so it shouldn't get included by most compilations units in typical GTK software. Software written for Windows from scratch typically tend to include <windows.h> in every file, though. But I don't think the actual time it takes to run gcc is what annoys people most when building stuff that uses auto*/libtool on Windows. For me, the most annoying part is libtool. This shell-script is mind-bogglingly slow. Running a configure script isn't exactly fast either, but you don't have to to that so often, and you can always catch up on your mail while configure is running, or something. But having to wait for libtool to figure out for the nth time how to invoke gcc is quite infuriating while you are in a test-edit-compile cycle. (For people used to MSVC, gcc's speed as such might also be an issue. I don't remember any numbers, but I think MSVC compiles several times faster.) --tml
