| |||||||||||||
Calligra 2.5 releasedCalligra 2.5 releasedPosted Aug 14, 2012 17:17 UTC (Tue) by 2NZb42fVtpOEyCBv (subscriber, #86247)In reply to: Calligra 2.5 released by Cyberax Parent article: Calligra 2.5 released
> That's probably a problem with the build system. MSVC itself is considerably faster than GCC, especially if you pass several source files at once.
True - for one project we rewrote our entire build system so that it passed all source files in a dir to the compiler at once, rather than the traditional (e.g. make implicit rules) approach of invoking the compiler once per source file. Transformed Windows build times. I think that it's to do with process creation being absurdly slow on Windows, but didn't look into it.
(That change then broke sparse, because there was a bug that cropped up when you pointed it at multiple source files - IIRC to do with scoping of static variables. Our patch for that got merged moons ago though.)
That makes our Windows builds tolerable. Still, the notion of having your project compilation mechanism dictated to you by the sloth of process creation on an "operating system" is laughable.
(Log in to post comments)
Calligra 2.5 released Posted Aug 14, 2012 17:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
No, it's cl.exe itself, it does a lot of startup initialization. I have no idea why, but it does.
Also, file system on Windows is excruciatingly slow. NTFS on Windows can literally be orders of magnitude slower than ext4 on Linux.
Calligra 2.5 released Posted Aug 14, 2012 17:36 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
That's what I said... The _filesystem_ is the problem, not the build system, not the speed of the compiler. I have tried with three different compilers on Windows, mingw, icl and mscv, on a spinning splatter and on ssd. It's the filesystem that makes life unbearable.
|
|||||||||||||