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

(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.)


Gimp-developer mailing list

Reply via email to