Since the gmake build system landed for Windows, we haven't been doing incremental linking of dlls, which can (I think) make depend builds a bit faster. I have a patch that I think should do this, although I'm probably not going to be able to test it until Monday.
This cuts the time needed to rebuild nsLayoutModule.obj and gklayout.dll from 26 seconds to 11 seconds for me. It seems to work just fine.
Attachment #129895 - Flags: review?(cls)
Comment on attachment 129895 [details] [diff] [review] patch Does MSVC's incremental linker properly handle the case where you remove files from the library?
I'm not sure. Was that broken back when we had the nmake build system?
I don't know; I avoid nmake whenever possible. Since release builds were almost always clobber builds, I don't think anyone bothered to check.
cls: per http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.incremental.asp: Additionally, LINK performs a full link if any of the following situations occur: [...] * An object (.obj) file is added or omitted. also... shouldn't this be done for executable files as well?
Comment on attachment 129895 [details] [diff] [review] patch rs=cls
Attachment #129895 - Flags: review?(cls) → review+
Comment on attachment 129895 [details] [diff] [review] patch This patch checked in, 2003-09-16 15:36/44 -0700. Leaving bug open to look into EXEs.
Component: Build Config → Build Config
Product: Mozilla Application Suite → Core
I noticed that the build system today seems to delete DLLs before linking them. Did something regress? Is this working as expected? Given the size of XUL.DLL, it sure would be nice to leverage incremental linking.
> I noticed that the build system today seems to delete DLLs before linking them. Nevermind. It's late, and I was imagining things.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.