Visual Studio 2017: How to use traditional multi-translation-unit builds for debug mode

[ne555]

I thought the whole point of unity build was to reduce build time.

perhaps

//in main.cpp
#ifndef DEBUG
//include all sources
#endif 

then you'll need to taylor the linking to just take main.o

[Repeater]

So, I'd like to stick with the old-fashioned way of building each cpp file independently when in debug mode to keep compile times fast when debugging, but switch to using a unity build for release mode to allow the compiler to optimize across translation unit boundaries

This sounds the wrong way around. Unity builds are meant to be faster, and unity builds have just one translation unit.

Although if your builds take around twenty seconds, I suspect you're not going to see any benefit at all from a unity build.

Yes, lots of what you've said doesn't make much sense in the context of unity builds.

[Niccolo]

I thought the whole point of unity build was to reduce build time.

...and, in my experience, it's a solution that can yield it's own problems.

If you have 6-12 cores and compile up to 12 units in parallel, a unity build could be a net loss.

If one enables "whole program" optimization, the unity build may not help with much in optimization.

If inline optimization is handled with functions in headers, unity build doesn't help.

[George P]

Spam links added in an edit.