We have been using VC6 for a very long time for our 1M line program.
When vc7 became available we ported the code to this platform. After sitting back and waiting for 5 minute links for a couple of months we went back to vc6 with a sob. The reason was the /PDBTYPE:SEPT being removed.
Now that vc8 is available we again ported all of our code up, an effort that has taken about a manmonth so far. We had seen some posts on MSDN where Microsoft people indicated that slow linking on vc7 was a concern, so we had some hopes that the bubble sort causing all this was being replaced...
All to be faced with what is now a 9 minute link time.
It is becoming increasingly impossible to go back to vc6 again as we also link third party libraries and want to use recent platform SDK calls. Also the pdb file size of 64Mbyte hits us hard on this platform.
But nine minutes to link every little code change before being able to test. That means just too much coffee running around our veins in a work day.
The cause for this situation is probably our cleverly design daily-build system which is devised to reduce compile times for our developers. Here's the deal:
All statically linked, native C++ code.
The program is subdivided into about 80 libraries, each with their own sln files. Maybe 20 cpp files average per lib.
These are built by an automated script on a special machine dedicated for the task. The output is a pdb and a lib file for each library.
These files get packed into a zip file along with the corresponding header files of the same versions and pushed to a server.
When a developer wants to upgrade his baseline he executes a script which unzipps all the libs and headers to the local environment.
Now it is possible to rebuild a single lib that has been changed locally and then easily link the entire application. This used to take around 40 seconds on vc6, which was acceptable if not swift. Now we face more than ten times this.
An important observation is that if we don't generate a pdb file the link time problem goes away. Alas we can't debug our program, which is what we intended to do in the first place...
Obviously we would want you to fix your linker, but as this is unlikely to happen we are at least hoping for some advice at how to reduce the impact. Here are some specific questions:
* Rumors on the internet have it that incremental linking doesn't work if lib files are included. Is this true?
* Would it be beneficial to create just one obj file in each lib by having the build machine create a "stdafx.cpp" which includes all the cpp files of the library?
* Would it be beneficial to lib the libraries together into one large library? If so, how can we modify a single of the original libraries when a developer has changed a file?
* We do run pch files in each (or at least a large part) of the libraries, but the set of include files included by each /Yc is different as we don't want a library to refer to a later library in the build order. Would it help our link times to have the same psh contents for all libraries?
Basically the problem is that we don't understand what aspect of our setup causes the extreme pdb-creation times. note that our build process essentially makes a clean build each time so we don't have lots of old junk laying around in the individual pdb files.
Please help, I don't know what we're going to do if we can't get this operating, we can't stay with vc6 forever!