Get rid of /Fo-related build slowdown

[GoogleCodeExporter]

There are a number of files that share the same name, requiring us to the 
specify that one (or more) of those files use a unique object file name. 
This is cumbersome to maintain using our current methodology, which is 
appending an oridinal (when we add the D3D 12 Device.cpp, is it 
Device4.obj? Device5.obj?). Getting this right is a cause of subtle build 
errors that typically will not manifest on the machine of the developer 
who adds the file right away.

But more annoyingly, using this option (/Fo) causes VS to compile that 
file in isolation rather than in bulk with the rest of the files that use 
the default object name -- examining BuildLog.htm will illustrate just how 
many unique .rsp files are generated. Each of these constitute spinning up 
a new cl.exe process, which starts to impact build time. VS will also 
abort the build and display errors for each cl.exe invocation in turn, 
which means you don't get great error coverage visibility when you happen 
to screw up really large changes.

Finding an alternative build or file name methodology that does not 
involve using /Fo so often on a per-file basis will be an improvement.

Original issue reported on code.google.com by josh.petrie on 1 Apr 2009 at 6:16

[GoogleCodeExporter]

This is fixed by all the file renaming we did.

Original comment by josh.petrie on 20 May 2009 at 4:20

• Changed state: Fixed

[GoogleCodeExporter]

*Mostly fixed. I haven't quite finished yet.

Original comment by promit....@gmail.com on 20 May 2009 at 4:46